The problem is that Tapestry runs one application per servlet, while spindle runs in a development environment where one could build multiple combinations of applications/components at the same time. The Application/Library spec defines its contents in a top-down fashion, sort of like defining a java package in a fictitious package.xml file and not in the classes themselves.
This works fine at runtime, as the focus/root/director (pick a term) is the Application. Any development tool, not just Spindle, is focussed on the file that you are editing at any particular time. Because the Tapestry components do not declare their membership in a Library or Application, its quite difficult to resolve the namespaces that are defined in the application. Need to ask the question: Which application? Which Library? Spindle can't infer this from any source like a file structure (used for java classes). It would have to ask the user every time something needed to be resolved and I'm sure that would get tiring right-quick. The simplest solution would be have pages and component declare their membership in their own specs. That's even worse than the restriction proposed by "Disallow spec path a comp. type" as it would destroy the ability to share components at all. Another solution was too add a rule in Spindle that would allow a component/page to be added to only one App or Library. Again less than ideal. What we needed was a way to infer the previous rule while still allowing one to re-use components. "Disallow spec path a comp. type" and the new project structure in Spindle is the best way we've come up with to get around the problem. The next version of Spindle includes the idea of a "Tapestry Project" which has a 1:1 relationship with an Application or Library spec. So, to resolve a namespace is easy, just find the project for the file, from that you get the App/Lib and then you can resolve the namespace. So, we've inferred the "one per" rule by the structure of the project. On the surface this might not seem to give much advantage but it does add a lot of flexibility. Here's how one uses this to one's advantage: A user has an application with pages and components that uses a Library. There are 3 ways to structure this: 1. The library is static. Simply include a jar file containing the Library in the application project's build path and add the library to the Application spec. All is good. In this configuration you can't do much with the files in the library. This is ok as the files are in a jar anyways and are therefore not editable! 2. The library is under development at the same time as the application. Create two projects, one for the application and one for the library. As in #1, add the library project to the build path of the Application. All is still good 'cause if you edit a library file, Spindle can correctly resolve namespaces as the Library->Project relationship exists. To deploy, create jar files for each project and include them in the servlet environment. 3. The last scenario would work but is less than ideal. Create one project for the application, then build it and some libraries in the same project. This is possible but namespace resolution for the library files will be wrong as all namespace resolution is in the context of the spec associated with the project (in this case the Application). Now that I've written it down I realize that this scenario is not really workable. It would be very hard to build the library correctly and very easy to build an unmanageable mess. As for making elements of a Library "private". Not a big deal for Spindle as it involves one extra step. One would need to qualify a namespace search with the namespace of the requestor. If a component in a library is marked "private", check that the namespace of the private thing and the requestor are the same. If not, throw an exception. BUT I speak for Spindle only. I have no idea if this is doable within the framework. That's a question for Howard. Geoff Geoffrey Longman Intelligent Works Inc. ----- Original Message ----- FROM: Richard Lewis-Shell DATE: 08/25/2002 20:56:06 SUBJECT: [Tapestry-developer] Re: [ tapestry-Bugs-599663 ] Disallow spec path a comp. type >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 ------------------------------------------------------- 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
