Re: Tapestry 5 thoughts

[Ron Piterman <rp...@gmx.net>]

Howard Lewis Ship wrote:
> I agree that <service> was easier than the HM approach, which is
> (infinitely) flexible.
> 
> Perhaps we just autowire the service instance with properties of
> matching type from the Infrastructure service.  So, if you need a
> LinkFactory in your service, just define a setter method that takes a
> LinkFactory parameter.
> 
> I made the decision that engine services would use HM because that's a
> very uncommon operation in Tapestry, as opposed to creating pages and
> components.
> 
> 
> I've been struggling with the following choice:
> 1) Keep backwards compatibility and evolve the code base (give or take)
> 2) Sacrifice backwards compatibility, but create the simpler, less
> ambiguous (easier to learn) framework people want
> 
> I'm prototyping some stuff right now that I'd have to call Tapestry 5.
>  I don't think there's a way to remove inheritance in the Tapestry 4
> code base without distorting many interfaces and breaking backwards
> compatibility.
> 
> My current vision is that the 4.1 code base will be about creating new
> components, including Ajax integration. Most of the innovation is
> present in the 3.0 -> 4.0 transition. Some new development may be to
> make certain things easier, such as re-introducing <service> in some
> way.

will ASOs also have their tapestry xml, instead of fundling around with 
hivemind conf-points?

What about the unit testing tapestry apps for tap 4.1 (or 
before/separate ) ?

> 
> 
> 
> 
> I'm starting to focus beyond that, on  Tapestry 5.  I'll be drawing
> out the code from Tapestry 4 and providing new code.  My vision is:
> - Annotations based.  JDK 1.5.
> - No XML for pages and components.  Just HTML and Annotations.
I can't really see the big advantage - maybe its just a personal 
flavour, but at the moment I like very much defining my components and 
beans in XML, parameters and properties in java/annotations - this keeps
my class clean and I know where to find what -
At the moment, the component annotations are not really something I 
would like to use, just like the bean ones, when setting a bunch of 
properties to the bean.

Its a kind of separation between declatations/functionality (parameters, 
properties) and actions (constructing a component).

Also I like to define which components/pages I have instead of letting 
tapestry discover them - its a king of control I like to have...

> - Concrete, not abstract, page and component classes
> - No inheritance imposition
> - Transforming class loader driven by annotations (i.e., @Persist on
> the field, not the method)
> - Change detection; automatic invalidate and reload of changed objects
> (including Java classes)
> - "Modern" templates:  Templates as wellformed XML, using a namespace
> for Tapestry attributes and elements
> - A "preview" mode for pages
> - Partial rendering of pages (for Ajax operations)
> - Improved management of page state (including dynamic state during the render)
> - Vastly simplified API
> - Clear deliniation between public/stable and private/internal/unstable APIs
> 
> On 1/31/06, Geoff Longman <gl...@gmail.com> wrote:
> 
>>This is OT from the original topic but that topic has spurred a
>>thought so while it's in my mind I'll regurgitate....
>>
>>One thing I'm not happy with is that users are forced to use HM in
>>certain places. For example engine services. Deprecation of <service>
>>was a bad thing.
>>
>>Why couldn't there be a convention (default contribution) that melds
>>services into the engine defined by <service> into HM without actually
>>needing to write HM xml? Move the complexity out of the user's hands
>>and into the framework. I've written dozens of Tapestry 3 services
>>without the *need* to inject anything (other than a few Spring beans
>>that is).
>>
>>If a user needs to inject, they use HM. I wonder (and I have not
>>written a Tap 4 service yet) if people are injecting many of the same
>>things into their services all the time? Or, why not make the services
>>abstract like components and inject via annotation?
>>
>>Hell, if <service> could be resurrected and make people's lives easier
>>why not user the peer idea Howard is talking about to make Tapestry 3
>>services work in Tap4+ without modification? This is a pipe dream
>>really, the interface has changed. There are ways to evolve interfaces
>>(Eclipse has this down pat) but at this point it's a matter of closing
>>the barn door after all the horses have bolted.
>>
>>I guess this boils down to a desire to keep the HM in the framework by
>>having conventions. The easiest choice is the right choice. When a
>>user needs to, they can use HM directly. A goal could be that 80% of
>>end user need to use HM directly 20% of the time.
>>
>>My 2 cents
>>
>>Geoff
>>
>>On 1/31/06, Geoff Longman <gl...@gmail.com> wrote:
>>
>>>Well, HM has contribution points already and they mirror Eclipse
>>>extension points/extensions to a degree.
>>>
>>>There's no reason why Shell couldn't use a contribution point to
>>>discover things like stylesheets to include.
>>>
>>>The trick would be to choose an implementation that is intuitive and
>>>easy to use.
>>>
>>>Define the mechanism end users would use to indicate something should
>>>be contributed to the shell. Preferably in a way that does not require
>>>the user to add thier own contribution in HM. Then create a default
>>>contribution that knows how to handle that mechanism. I don't know
>>>that that mechanism is as I'm not clear on what you are trying to
>>>achieve. its a topic for discussion
>>>
>>>Convention over Customization (as the rails people would say).
>>>
>>>That way you have an easy way and the hard way. The easy way is to use
>>>the convention (default contribution). The hard way is to invent your
>>>own custom handler and wire it into the HM contribution point. Good
>>>for weird custom cases.
>>>
>>>That way everybody's happy.
>>>
>>>Make sense?
>>>
>>>Geoff
>>>
>>>On 1/30/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>>>
>>>>hey geoff (or anyone else),
>>>>
>>>>Do you think any of the rcp extension sort of designs might apply to
>>>>portions of tapestry? A friend of mine has mentioned it twice to me and
>>>>today it started to click a little bit more. (Especially with my recent
>>>>discoveries of the Delegate parameter in Shell and others) .
>>>>
>>>>jesse
>>>>
>>>>
>>>
>>>
>>>--
>>>The Spindle guy.          http://spindle.sf.net
>>>Get help with Spindle:
>>>http://lists.sourceforge.net/mailman/listinfo/spindle-user
>>>Blog:                     http://jroller.com/page/glongman
>>>Feature Updates:          http://spindle.sf.net/updates
>>>
>>
>>
>>--
>>The Spindle guy.          http://spindle.sf.net
>>Get help with Spindle:
>>http://lists.sourceforge.net/mailman/listinfo/spindle-user
>>Blog:                     http://jroller.com/page/glongman
>>Feature Updates:          http://spindle.sf.net/updates
>>
>>---------------------------------------------------------------------
>>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
> 
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com


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