I can see the importance of spindle and libraries. They both look cool. Perhaps there is another way to solve this problem though - as it stands, you are saying that ALL components must be aliased/declared in a library, or application specification. (right?)
Can a component (or page for that matter) be hidden inside a library? ie. not available to be re-used outside that library. (Much like private fields/methods in Java) If I have a page that requires a some of it to be put in a component, and that component is specific to that page (and thus useless to any other page/component) then I must alias/declare that component to either the entire application, or (worse?) to anyone using the library that contains the page. Name clashes aren't really the problem here so much as hiding the internals of a page. Perhaps a page could be considered a mini-library so such a component could be defined in the page only? (I don't know much about spindle or libraries, so this could be way off!) R ----- Original Message ----- From: "Howard M. Lewis Ship" <[EMAIL PROTECTED]> To: "Richard Lewis-Shell" <[EMAIL PROTECTED]> Cc: "Tapestry Developer" <[EMAIL PROTECTED]> Sent: Monday, August 26, 2002 2:46 PM Subject: Re: [ tapestry-Bugs-599663 ] Disallow spec path a comp. type > It's to support a lot of features in Spindle. Spindle has been severely > inconvienienced by the ability to put arbitrary specification paths in as > the contained component type. Thiis has gotten much more complicated with > the addition of libraries. Basically, Spindle needs to be able to relate a > page or component specification back to a containing library or application > so that it can provide assistance and validation. This solution was less > egregious than having each page or component point back to the > library/application that contains it. It removes some ambiguities that > allows Spindle to built the map between components and libraries on its own. > > I'm sorry, but I feel that both Spindle and libraries are critical to the > maturation of Tapestry into a broadly used standard. > > If ou are concerned with name collisions, consider using libraries within > your application. > > Sorry for any inconvienience; I hope it is outwieghed by the great new > features in 2.2. > > Howard > > ----- Original Message ----- > From: "Richard Lewis-Shell" <[EMAIL PROTECTED]> > To: "Howard M. Lewis Ship" <[EMAIL PROTECTED]> > Sent: Sunday, August 25, 2002 10:16 PM > Subject: Re: [ tapestry-Bugs-599663 ] Disallow spec path a comp. type > > > > Why is this? I have just convinced my developers that things that > > components that aren't to be shared across the entire application don't > need > > to be aliased in the application file as they can just use the entire > > specification path in the component type attribute. > > > > R > > > > ----- Original Message ----- > > From: "Howard M. Lewis Ship" <[EMAIL PROTECTED]> > > To: "Richard Lewis-Shell" <[EMAIL PROTECTED]> > > Sent: Monday, August 26, 2002 2:09 PM > > Subject: Re: [ tapestry-Bugs-599663 ] Disallow spec path a comp. type > > > > > > > Starting with component specification 1.3 that is correct. It is still > > > allowed in the 1.1 and 1.2 specifications. > > > > > > ----- Original Message ----- > > > From: "Richard Lewis-Shell" <[EMAIL PROTECTED]> > > > To: "Howard Lewis Ship" <[EMAIL PROTECTED]> > > > Sent: Sunday, August 25, 2002 4:38 PM > > > Subject: Re: [ tapestry-Bugs-599663 ] Disallow spec path a comp. type > > > > > > > > > > Hi there, > > > > > > > > What does this mean exactly? As I read it, it means that one cannot > do > > > > this: > > > > <component id="banana" type="/path/to/my/Banana.jwc" /> > > > > > > > > Is that correct? > > > > > > > > R > > > > ----- Original Message ----- > > > > From: <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Sunday, August 25, 2002 4:11 AM > > > > Subject: [Tapestry-developer] [ tapestry-Bugs-599663 ] Disallow spec > > path > > > a > > > > comp. type > > > > > > > > > > > > > Bugs item #599663, was opened at 2002-08-24 12:05 > > > > > You can respond by visiting: > > > > > > > > > > > > > > > https://sourceforge.net/tracker/?func=detail&atid=104754&aid=599663&group_id > > > > =4754 > > > > > > > > > > Category: Tapestry > > > > > Group: bug > > > > > >Status: Closed > > > > > >Resolution: Fixed > > > > > Priority: 5 > > > > > Submitted By: Howard Lewis Ship (hship) > > > > > Assigned to: Howard Lewis Ship (hship) > > > > > Summary: Disallow spec path a comp. type > > > > > > > > > > Initial Comment: > > > > > Starting in specification 1.3, specification paths should > > > > > NOT be allowed as a component type (<component> > > > > > element, type attribute). > > > > > > > > > > This is valid in the earlier DTDs (1.1 and 1.2) but not for > > > > > 1.3. Backwards compatibility should be maintained. > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > You can respond by visiting: > > > > > > > > > > > > > > > https://sourceforge.net/tracker/?func=detail&atid=104754&aid=599663&group_id > > > > =4754 > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This sf.net email is sponsored by: OSDN - Tired of that same old > > > > > cell phone? Get a new here for FREE! > > > > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > > > > _______________________________________________ > > > > > Tapestry-developer mailing list > > > > > [EMAIL PROTECTED] > > > > > https://lists.sourceforge.net/lists/listinfo/tapestry-developer > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
