tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Tapestry 3.1 status
Date Wed, 03 Nov 2004 17:35:19 GMT
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 <hlship@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

To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message