> - Concrete, not abstract, page and component classes Nice
> - No inheritance imposition Nice > - Change detection; automatic invalidate and reload of changed objects > (including Java classes) Awesome > - Improved management of page state (including dynamic state during the > render) Really needed. > - Vastly simplified API > - Clear deliniation between public/stable and private/internal/unstable APIs That would be just great and hopefully alow you have backwards compatibility from then on. If you achieve all of the above the result can be just wonderful. IMVHO I think we (the users) will accept breaking backwars compatibility happily. Regards Pedro > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
