What about this: - add a package prefix(s) parameter (such as "com.mycompany.thewebapp"), this can be specified in a servlet config-param. Visit can also be specified with a config-param. No need for an application xml file in most cases then.
- map *.jwc to tapestry servlet, so when a request for a jwc url comes just prefix it with the prefix parameter, load the jwc file, assume the html file is collocated there two and maybe even check for the BasePage-derived class with that prefix+page name too. - another irrelevant suggestion: write a helper tool which reads a jwcid-annotated html file and generates the jwc file. It can be smart: for example if you put <textfield jwcid="someTextField" .../> then the tool generates a <component name="someTextField" type="TextField"...>. You can use some merge/diff techniques too (like xmlunit), so you'll be able to run it continuously from your ant build for example. This way we'll have no jsp taglib mess, and no orphan jwcid components. Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:tapestry- > [EMAIL PROTECTED]] On Behalf Of Drew Davidson > Sent: Friday, October 25, 2002 1:38 AM > To: Howard M. Lewis Ship > Cc: Sacha Labourey; Tapestry-Developer ML > Subject: Re: [Tapestry-developer] Suggestions for Tapestry (long post) > > Howard M. Lewis Ship wrote: > > >I've been making some progress towards the goals of "Tapestry Lite". > > > > > I think that a worthy goal toward this would be to package up only (a) a > WEB-INF/web.xml file specifying the servlet path, class, etc. for a > built-in ApplicationServlet class, and (b) a single template set (html, > page/jwc) and have that be able to work without any other infrastructure > (like the "Hello, World" app). So you'd be able to use it without > having to modify the application's .xml file just to get started. I > think these all fall into the area of "reasonable defaults". I could be > completely off my rocker, of course. > > >I'm a bit more nervous about the idea of scanning for .pages. First off, > it > >represents a shift in Tapestry from storing page (and component) > >specifications in the classpath to storing them in the web application > >context (i.e., alongside static HTML and assets). Also, I'm not aware of > a > >completely portable way to "scan" for files ... you would need to do a > bit > >of work to down cast ClassLoader to specific implementations that had the > >necessary methods. I'm not even sure which ClassLoader methods I'd need > ... > >probably have to get to URLClassLoader, query the URLs, work from there. > >Messy (but doable). > > > > > The way that I've found works in my own frameworks is to have a special > "component loader" that can find components by searching the path of (a) > ServletContext.getResource(<resourceName>) then (b) > ServletContext.getResource("WEB-INF/templates/" + <resourceName>). That > way templates and other private assets are excluded if you want them to > be but the loader can always find them. > > >Anyway, where I'm headed now is Tapestry Lite, with big flaming warning > >signs, but > >- You can put your HTML files in the web app context (at the root) > >- An "implicit" specification will be generated from such HTML files > >- The HTML file can specify the Java page class > >- You can define components (ids, types and bindings) in the HTML (I call > >these "implcit components", vs. the "declared components" of traditional > >Tapestry) > >- You don't need an app specification (initially) > >- You can mix and match Tapestry Lite with traditional Tapestry, so when > a > >page becomes too complex to be implicit, you can create a .page for it > and > >register the .page in the .application > > > > > I think these changes will be for the best. Most people balk at the > idea that everything must be in the declarations and only a small token > (jwcid="name") has to be parsed and looked up just to find the > declaration. On complicated pages this can be frustrating to have to > look up definitions. > > >Also, I think (in the long run) a lot of components are going to "go > >implicit". Components that generally don't take formal parameters (such > as > >Body) can simply be <body jwcid="@Body"> and be done with it. Likewise, > >most Inserts and Conditional components can be implicit. The downside to > >implciit components is > >a) Back to JSP problems when you have multiple localized templates > (though > >mostly localization is done through strings now) > >b) How to interpret the attributes in the HTML template: as OGNL > >expressions or a static strings? > > > > > I have dealt with this with WebOGNL by having two types of attribute > values: string and expression. > > Strings are as you normally see: > > <ognl:string value="This is a normal String value"/> > > Expressions allow OGNL code inside and are converted by my custom XML > parser: > > <ognl:string value="[currentValue.substring(2, 4)]"/> > > So I think that you might want to delimit OGNL expressions differently - > perhaps with brackets, they seem to look most natural in the flow of > things. > > >(b) is the vexing problem ... to the point that I'm thinking that to > >maintain sanity, I may have to introduce (<binding name=".." > >expression=".."/> into the HTML template to support implicit components. > Or > >I may have attributes that exactly match a formal parameter be treated as > >OGNL expressions, and other attributes treated as static strings (as all > >informal parameters are today). > > > > > I look forward to hearing your thoughts on my comments... > > - Drew > > -- > +---------------------------------+ > < Drew Davidson | OGNL Technology > > +---------------------------------+ > | Email: [EMAIL PROTECTED] / > | Web: http://www.ognl.org / > | Vox: (520) 531-1966 < > | Fax: (520) 531-1965 \ > | Mobile: (520) 405-2967 \ > +---------------------------------+ > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en > _______________________________________________ > Tapestry-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/tapestry-developer ------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
