On Tue, 25 May 1999, Robert A. Crawford wrote:
>.....
> On Tue, May 25, 1999 at 11:30:58AM +0300, Cezar Totth wrote:
> > That's why I'm asking again all template-engine developers on this list
> > if it isnt the time to share opinion and try to set some sort of
> > standard to allow:
> > - Template inter-operability - making switching from one template
> > engine to another easier for application developer.
> > Or even interoperability betwen template engines, like
> > including one template using JSP in another template
> > using webmacro, and BOTH sharing the same
> > variable/name/object space...
>
> I don't know what this would take. On the surface, WebMacro
> and FreeMarker use similar-looking names to resolve variables, but
> I know the internal representations are wildly different.
This would take to separate the introspection engine from the actual
template parser/interpreter. These engine would share a common
interface that would allow multiple template systems to use
another's "data accessing engine"
...
>
> > - More powerfull features lacking now in most template systems
> > (including JSP) like:
> > - Mapping betwen input form fields and setXXX() calls
>
> I don't know what this means.
>
This means that witin the same template where a FORM is defined,
to specify how the submitted input fields would be directly mapped to
calls of "setProperty(submittedValue)" within the same objects that
are accessed for display.
For example, with an "#Lookup.Here#" notation:
<FORM NAME=EditUserInfo ACTION="SomeOtherTemplate?#TemplateID#">
<INPUT TYPE=TEXT NAME=ChangedAge VALUE="#Session.User.Age#">
...
<MapInput PropertyName=Session.User.Age InputField="ChangedAge">
</FORM>
So considering the "User" object as a bean with getAge() setAge()
calls using a template engine would be enough to use them, without
The advantage here is perhaps not obvious from the point of view
of classic servlet development:
just by adding the #TemplateId# macro within form's action URL,
will give the template complete independence from where the action
URL points (if "SomeOtherTemplate" points to a template "within" the same
engine. That means a template designer has both control and freedom
on the user-interface "flow" not only on its "look-and-feel".
The application developer will not even need to handle user-interface
logic within servlets, it will be enough to offer abstractions
like "beans", "factories", "data formatters", "components" ...
and allowing that in 90% of the cases both look&feel *and*
user interaction to be specified, as *simple* as possible,
from within templates.
Some people mentioned on this list a model-view-controller approach:
- the bussiness logic, rules, and data are the "model".
- the template is the "view".
- the servlet acting as a controller betwen model and view.
Having template system(s) capable to take a functions from the
"controller" side could be interesting.
Dont believe JSP should be the unique "standard" for this purpose.
......
> > - exception handling within templates.
>
> I'm not sure what you mean. My servlets that use templates
> have followed this general pattern:
> ....
Well, if a template is capable to call "setProperty()"
methods within beans it also needs to be able to handle exceptions.
>From the template-designer point-of-view this means:
- Knowing what kind of exceptions can occur by setting ... let say
an "Age" property - (negative values, number format exception..)
- Choosing either:
- What template to be displayed when a specific exception occurs.
- not to allow the user to "go" further, by simply
displaying the same template with proper, explicit error messages,
so user can see what is going wrong (no matter what
the form's action is - the "SomeOtherTemplate" url)
----------------------------------
Other feature I didnt mention might be showing
"default" content for nulls - that means a way to display "Unknown
address" if user.getAddress() returns
null object.
>From a template-approach this is rather simple (comprehensive for
html-based interface designer):
<ShowData
PropertyName=Session.User.Address
NullValue="Unknown Address"
>
rather than the equivalent Java from inside or outside JSP:
MyUserClass user = (MyUserClass) session.getValue("User");
if(user == null) out.println("Unknown Address");
else {
String address = user.getAddress();
if(address == null) out.println("Unknown address"); /* again */
else out.println(address);
}
(not mentioning the need to explain to the template designer the need for
"include" tags at top of .jsp and "what" and "from where" the "out"
thing is coming, or what is the difference betwen "class" and "instance",
casting, why & what a "null" is good for ...)
Cezar.
....
> try {
> 1. Get input from form.
> 2. Process business logic.
> 3. Construct template
> 4. Write output.
> }
> catch (SomeException) {
> log it
> hand off to a "we screwed up" page
> }
>
> Any exceptions I can handle in the logic, well, I handle
> those. The template doesn't enter into the equation.
>
> > - automatic internationalisation (like choosing a template source
> > depending on user's language prefferences)
>
> This is a good idea, IMHO. It could be implemented in
> WebMacro's TemplateProvider or FreeMarker's TemplateCache.
>
> > - output diverting...
>
> I'm not sure what you mean. All of the template packages
> I've seen use java.io.Writer or some subclass as their interface.
> You can manipulate that as you need.
>
> > - Output stream buffering - allowing:
> > - adding response headers during/after template processing
> > (e.g. Content-Length)
>
> Possibly there should be an alternative method for sending
> the template's content to the browser. Possibly
> "Template.sendResponse(HttpServletResponse resp)", that handles
> setting the correct content type and length before writing the
> template content out.
>
> I like this idea.
>
> > - a more sophisticated exception handling, like dispatching
> > the response to a different resource, when something
> > goes wrong, even output has been written
>
> I think this should be the job of the servlet developer.
> See above.
>
> > - easy-to-use formatting for dates, numbers, other objects...
>
> I _really_ like this idea, especially if it can be tied into
> internationalization.
>
> --
> Robert Crawford [EMAIL PROTECTED]
> http://www.iac.net/~crawford
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
