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.
Sure and I'm not knocking the choice. But after the fact seeing the traffic on the list it appears to be a fairly common task. Every Tapestry project I've ever worked on includes services. I think that if conventions are created and user's can avoid HM in many cases they will happier. Even more happy when they know the "weapon" called HM is in the holster for those 'reinventing the space shuttle' cases. I'm liking the 'peer' idea more and more. Things like injection could be, instead of an enhancement task, a cue to the 'peer' that injection is needed on a POJO. > > > 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 We're smart, some things may be savable. I'm starting to sound like a broken record but the Eclipse folks have had a lot of success evolving their api. > > 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. why not a check, if it's the old way the class *is* the peer. Otherwise it's new and a peer is created. Depends on how you are approaching the new stuff > > 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. Sounds great to me. > > > > > 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. My vote on this is +1 with an added proviso. A page/component class must have an annotation like @TapestryPage/@TapestryComponent.Something a tool can use to cull the little buggers based on the package decl in the namespace. I'm worried mostly about completely specless components and tool support. Pages are turning out to be not too bad, they have a template and tools can work backwards from that. But how will a tool like tapidea or spindle locate specless components? One could go by reachability - a page/component refers to a component - tool looks for it when it is referenced. But, imho that approach lessens the usefulness of the tool as it would be impossible to validate the component until it is referenced. > - 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] > > -- 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]
