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, itThe 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.
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).
Anyway, where I'm headed now is Tapestry Lite, with big flaming warningI 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.
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
Also, I think (in the long run) a lot of components are going to "goI have dealt with this with WebOGNL by having two types of attribute values: string and expression.
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?
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 toI look forward to hearing your thoughts on my comments...
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).
- 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
