Cool. Thanks for having a look. The issues I laid out w/respect to implicit namespace bounday crossing have become clearer to me as I stuggle with implementing Spindle for T4.
Note though, that I present my findings/suggestions in the context of the Tapestry implementation and useablility, not in the context of tool support. While some tweaks to Tapestry would make building tools easier, and I welcome any such consideration in future versions, I have figured out how Spindle will address these issues for T4. Geoff On 2/17/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I'm home for a few days; I'm printing this out to try and guage what's > going on. I'm expecting that we may find some things Geoff is afraid > people will try to do that we may add checks for (to make illegal). > Or maybe we'll find another solution. > > On 2/12/06, Apache Wiki <[EMAIL PROTECTED]> wrote: > > Dear Wiki user, > > > > You have subscribed to a wiki page or wiki category on "Jakarta-tapestry > > Wiki" for change notification. > > > > The following page has been changed by GeoffLongman: > > http://wiki.apache.org/jakarta-tapestry/Tapestry5LookupDebate > > > > ------------------------------------------------------------------------------ > > }}} > > Is a user supplied class used to resolve pages when all else fails. > > Since the developer of the application supplies an implementation of > > `ISpecificationResolverDelegate`, no implicit boundary crossing can occur > > anyways. The implementation of Tapestry is free from responsibility. > > > > + And that's it for lookup rules. As a lark, I changed my local copy of > > Tapestry 3 to conform to my suggestions (not the alias tags though). At > > work here we have a Tapestry 3 application, otherwise I would have hacked > > the Tapestry 4 code. This app has over 300 pages and components (in total) > > and runs without any error I have been able to find so far. I suspect the > > same would be true if I had hacked up the Tapestry 4 source code. Perhaps > > not a good example as the application is proprietary and I can't share any > > implementation details. But one could take this as a sign that my suggested > > changes are not catastrophic. > > + > > + There is one more issue. In Tapestry 3.0.2 or 3.0.3 a change was made to > > allow libraries to be defined in the context instead of the traditional > > place (the classpath). In Tapestry 3 I don't see this as a big deal but in > > Tapestry 4 this in effect makes every library page/component implicity a > > member of every application namespace in the war file. That's not good. I > > would suggest that libraries longer be allowed to be defined in the context. > > + > > + Although, I may be missing something here. Help me out. Why was this > > change made? In other words, why is it a good thing that libraries can be > > defined in the context? > > + > > + This is the end of the comments I wanted to talk about. > > + > > + Rip away. > > + > > > > --------------------------------------------------------------------- > > 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]
