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]
