You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2004/11/02 13:07:50 UTC
Tapestry 3.1 status
Things are going quite nicely on the Tapestry 3.1 front.
I just coded the <inject> specification element. <inject> allows a
HiveMind service (or configuration, etc. ... it leverages the same
code as the object translator) to be injected into components as
component properties. Example:
<inject name="mailSender" object="service:mymodule.MailSender"/>
<inject name="toolbarItems"
object="configuration:app.ui.toolbar.ToolbarItems"/>
Or even:
<inject name="directService" object="engine-service:direct"/>
(I just have to add an ObjectProvider for the engine-service: prefix.
Piece of cake).
What's great is that I'm getting 100% code coverage without resorting
to cumbersome integration tests (the mock unit tests, driven by the
.xml files).
I'm very much looking forward to "throwing open the gates". I've been
having a struggle with Forrest 0.6 that I hope to resolve at some
point and I have a little bit of work involving parameters (getting
rid of parameter direction) and engine services.
Tapestry is transforming yet again with the change from 3.0 to 3.1.
It's in my nature to only the see the faults in my work; so while I
delight in the news I hear of Tapestry adoption, I'm always concerned
that others will see its warts. Perhaps I suffer from "next release
syndrome", but I think people will be hard pressed to find those warts
in 3.1!
I think it will be useful for others to start discussing the work they
expect to start doing on 3.1. Paul's talked about improving form
validation, as has Harish. Erik or MindBridge has talked about
retrofitting Foreach and Conditional to work inside Forms (as with
FormConditional and ListEdit today). I've been thinking in terms of
dealing with many other issues with Forms, such as handling cancels,
and refreshes properly, and untangling the mess of event handlers on
the client side.
There's the sad fact of all the documentation (particularily the new
component reference) that must be done ... this is currently hostage
to problems I'm having with Forrest 0.6. All Tapestry 3.1
documentation will now be generated from Forrest .xml files; no raw
HTML, no DocBook.
So far I've done exactly one component, Insert:
http://jakarta.apache.org/~hlship/tapestry/tapestry/ComponentReference/Insert.html
There are placeholders for the other components in the framework.
There is nothing for the WML library, or for the components in the
contrib library.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 3.1 status
Posted by Howard Lewis Ship <hl...@gmail.com>.
Just checked in the code changes to support automatic creation of properties.
If you have an abstract accessor in your code, i.e.:
public abstract String getFoo();
There's now no need to put the following in the spec:
<property name="foo"/>
In 3.0, you had to ... and you had to specify the type
("java.lang.String") to boot.
In 3.1, you only need to provide a <property> element if one of the
following is true:
- The property is persistent
- You want a property, but don't access it in code, so no accessor method
- You want to specify an initial value for the property
And even in the later case (initial value), you can do so by
overriding finishLoad() and setting a value for the property there.
So this is very good ... there were some flagrant violations of the
Dont Repeat Yourself priniciple going on in 3.0. "Less is more!" is
the rule for 3.1.
On Tue, 2 Nov 2004 07:07:50 -0500, Howard Lewis Ship <hl...@gmail.com> wrote:
> Things are going quite nicely on the Tapestry 3.1 front.
>
> I just coded the <inject> specification element. <inject> allows a
> HiveMind service (or configuration, etc. ... it leverages the same
> code as the object translator) to be injected into components as
> component properties. Example:
>
> <inject name="mailSender" object="service:mymodule.MailSender"/>
> <inject name="toolbarItems"
> object="configuration:app.ui.toolbar.ToolbarItems"/>
>
> Or even:
>
> <inject name="directService" object="engine-service:direct"/>
>
> (I just have to add an ObjectProvider for the engine-service: prefix.
> Piece of cake).
>
> What's great is that I'm getting 100% code coverage without resorting
> to cumbersome integration tests (the mock unit tests, driven by the
> .xml files).
>
> I'm very much looking forward to "throwing open the gates". I've been
> having a struggle with Forrest 0.6 that I hope to resolve at some
> point and I have a little bit of work involving parameters (getting
> rid of parameter direction) and engine services.
>
> Tapestry is transforming yet again with the change from 3.0 to 3.1.
> It's in my nature to only the see the faults in my work; so while I
> delight in the news I hear of Tapestry adoption, I'm always concerned
> that others will see its warts. Perhaps I suffer from "next release
> syndrome", but I think people will be hard pressed to find those warts
> in 3.1!
>
> I think it will be useful for others to start discussing the work they
> expect to start doing on 3.1. Paul's talked about improving form
> validation, as has Harish. Erik or MindBridge has talked about
> retrofitting Foreach and Conditional to work inside Forms (as with
> FormConditional and ListEdit today). I've been thinking in terms of
> dealing with many other issues with Forms, such as handling cancels,
> and refreshes properly, and untangling the mess of event handlers on
> the client side.
>
> There's the sad fact of all the documentation (particularily the new
> component reference) that must be done ... this is currently hostage
> to problems I'm having with Forrest 0.6. All Tapestry 3.1
> documentation will now be generated from Forrest .xml files; no raw
> HTML, no DocBook.
>
> So far I've done exactly one component, Insert:
> http://jakarta.apache.org/~hlship/tapestry/tapestry/ComponentReference/Insert.html
>
> There are placeholders for the other components in the framework.
> There is nothing for the WML library, or for the components in the
> contrib library.
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 3.1 status
Posted by Howard Lewis Ship <hl...@gmail.com>.
Currently, you can do:
<inject name="myProperty" object="service:mymodule.myService"/>
The key thing here is the "service:" prefix; that's what clues
HiveMInd in that the rest of the string is a service ID.
However, theres a configuration point, hivemind.ObjectProviders, that
allows you to supply your own prefixes and rules.
http://jakarta.apache.org/hivemind/hivemind/ObjectProviders.html
I will, when I catch my breath, add a spring: prefix to access Spring
beans. There'll be some other little bit of configuration to identify
where the Spring ApplicationContext is.
This approach is very nice; I'll also be adding a engine-service:
prefix to directly connect pages and components to Tapestry engine
services (which are now HiveMind services). No more de-referencing
via the IRequestCycle and IEngine!
On Wed, 03 Nov 2004 15:11:56 -0500, Colin Sampaleanu <co...@exis.com> wrote:
> Howard,
>
> Can you provide more details about how HiveMind is plugged in here? I'm
> interested in the possibility of injecting service objects from a Spring
> application context, ideally via the same element. The current approach
> that some people use, to get at Spring managed services, is to bind via
> the initial value on the <property> tag. That works, but is nowhere near
> as clean as this looks to be.
>
> Regards,
> Colin
>
>
>
>
> Howard Lewis Ship wrote:
>
> >Things are going quite nicely on the Tapestry 3.1 front.
> >
> >I just coded the <inject> specification element. <inject> allows a
> >HiveMind service (or configuration, etc. ... it leverages the same
> >code as the object translator) to be injected into components as
> >component properties. Example:
> >
> > <inject name="mailSender" object="service:mymodule.MailSender"/>
> > <inject name="toolbarItems"
> >object="configuration:app.ui.toolbar.ToolbarItems"/>
> >
> >Or even:
> >
> > <inject name="directService" object="engine-service:direct"/>
> >
> >(I just have to add an ObjectProvider for the engine-service: prefix.
> >Piece of cake).
> >
> >What's great is that I'm getting 100% code coverage without resorting
> >to cumbersome integration tests (the mock unit tests, driven by the
> >.xml files).
> >
> >I'm very much looking forward to "throwing open the gates". I've been
> >having a struggle with Forrest 0.6 that I hope to resolve at some
> >point and I have a little bit of work involving parameters (getting
> >rid of parameter direction) and engine services.
> >
> >Tapestry is transforming yet again with the change from 3.0 to 3.1.
> >It's in my nature to only the see the faults in my work; so while I
> >delight in the news I hear of Tapestry adoption, I'm always concerned
> >that others will see its warts. Perhaps I suffer from "next release
> >syndrome", but I think people will be hard pressed to find those warts
> >in 3.1!
> >
> >I think it will be useful for others to start discussing the work they
> >expect to start doing on 3.1. Paul's talked about improving form
> >validation, as has Harish. Erik or MindBridge has talked about
> >retrofitting Foreach and Conditional to work inside Forms (as with
> >FormConditional and ListEdit today). I've been thinking in terms of
> >dealing with many other issues with Forms, such as handling cancels,
> >and refreshes properly, and untangling the mess of event handlers on
> >the client side.
> >
> >There's the sad fact of all the documentation (particularily the new
> >component reference) that must be done ... this is currently hostage
> >to problems I'm having with Forrest 0.6. All Tapestry 3.1
> >documentation will now be generated from Forrest .xml files; no raw
> >HTML, no DocBook.
> >
> >So far I've done exactly one component, Insert:
> >http://jakarta.apache.org/~hlship/tapestry/tapestry/ComponentReference/Insert.html
> >
> >There are placeholders for the other components in the framework.
> >There is nothing for the WML library, or for the components in the
> >contrib library.
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 3.1 status
Posted by Colin Sampaleanu <co...@exis.com>.
Howard,
Can you provide more details about how HiveMind is plugged in here? I'm
interested in the possibility of injecting service objects from a Spring
application context, ideally via the same element. The current approach
that some people use, to get at Spring managed services, is to bind via
the initial value on the <property> tag. That works, but is nowhere near
as clean as this looks to be.
Regards,
Colin
Howard Lewis Ship wrote:
>Things are going quite nicely on the Tapestry 3.1 front.
>
>I just coded the <inject> specification element. <inject> allows a
>HiveMind service (or configuration, etc. ... it leverages the same
>code as the object translator) to be injected into components as
>component properties. Example:
>
> <inject name="mailSender" object="service:mymodule.MailSender"/>
> <inject name="toolbarItems"
>object="configuration:app.ui.toolbar.ToolbarItems"/>
>
>Or even:
>
> <inject name="directService" object="engine-service:direct"/>
>
>(I just have to add an ObjectProvider for the engine-service: prefix.
>Piece of cake).
>
>What's great is that I'm getting 100% code coverage without resorting
>to cumbersome integration tests (the mock unit tests, driven by the
>.xml files).
>
>I'm very much looking forward to "throwing open the gates". I've been
>having a struggle with Forrest 0.6 that I hope to resolve at some
>point and I have a little bit of work involving parameters (getting
>rid of parameter direction) and engine services.
>
>Tapestry is transforming yet again with the change from 3.0 to 3.1.
>It's in my nature to only the see the faults in my work; so while I
>delight in the news I hear of Tapestry adoption, I'm always concerned
>that others will see its warts. Perhaps I suffer from "next release
>syndrome", but I think people will be hard pressed to find those warts
>in 3.1!
>
>I think it will be useful for others to start discussing the work they
>expect to start doing on 3.1. Paul's talked about improving form
>validation, as has Harish. Erik or MindBridge has talked about
>retrofitting Foreach and Conditional to work inside Forms (as with
>FormConditional and ListEdit today). I've been thinking in terms of
>dealing with many other issues with Forms, such as handling cancels,
>and refreshes properly, and untangling the mess of event handlers on
>the client side.
>
>There's the sad fact of all the documentation (particularily the new
>component reference) that must be done ... this is currently hostage
>to problems I'm having with Forrest 0.6. All Tapestry 3.1
>documentation will now be generated from Forrest .xml files; no raw
>HTML, no DocBook.
>
>So far I've done exactly one component, Insert:
>http://jakarta.apache.org/~hlship/tapestry/tapestry/ComponentReference/Insert.html
>
>There are placeholders for the other components in the framework.
>There is nothing for the WML library, or for the components in the
>contrib library.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org