anyone mind if I start a tapestry5 wiki page with some of howards original post here?
On 1/31/06, Howard Lewis Ship <[EMAIL PROTECTED]> 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. > > > > > 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. > - 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
