[Mav-user] a new view
I recently had reason to develop a new view type for Maverick, and
wonder if there might be any interest in it. If so, perhaps I can
contribute it back to the project.
The problem: I needed a very simple X?HTML template system. It had to
be something that, however, complicated under the hood, could be used
by junior developers and design people. I also wanted the source
pages to be valid XML, so that I could use the various XML tools to
edit/process/test the pages.
I wanted to avoid JSP's scriptlet syntax. JSTL might work, but I
wanted the source pages to be valid XML, so I wanted to avoid stuff
like
a href=c:out value='...'/ ... /a
Basically, I wanted XML source files, with the ability to dynamically
evaluate expressions and a some minimal amount of flow control.
Looping, for sure. Conditionals, probably. Something to match the
minimalist spirit of Maverick itself.
Something that might look like this (with some of the namespace stuff
cleared away):
html
body
h2Welcome ${user.fullName}/h2
Your order contains the following items:
table
ctl:for-each items='${order.items}' name='item'
trtd${item.productId}/tdtd${item.description}/td/tr
/ctl:for-each
/table
the current time is ${util.dateTime}
/body
/html
looks a bit like JSTL, but is required to be valid XML, unlike
JSP+JSTL. I used OGNL for the expression language.
The processing model goes like this: the page description (e.g. the
above sample) is loaded once at app startup and parsed as a stream of
SAX events. The events are recorded, and we do a certain amount of
pre-processing, e.g. joining and compiling text nodes. Then, at
request time we replay the event stream using a request specific
evaluation context that contains things like the current request,
the authenticated user, and some utilities. Maverick makes this
pretty simple, because we can grab the next transform step in the
view handler, and send the replayed SAX events on down the line.
This means that any XSTL we might want to perform can be specified in
Maverick's config, and will be handled completely by Maverick.
Another nice thing about this is that unlike using JSP+XSLT, where
the output of the JSP has to be re-parsed on every request, in my
system the source is parsed exactly once.
The strange thing about all this is that I wasn't able to find
anything that quite suited my purpose. So I guess that's one purpose
of this message: to see what I may have missed in the sea of Java
webapp frameworks.
The other purpose is to see if there's any interest in this. If not,
then I must have missed something, because I've been quite pleased
with the results. If so, then I can see about getting it cleaned up
and put out somewhere for the Maverick community to have a look at.
--
joe
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
[INVALID FOOTER]
Re: [Mav-user] a new view
Hmmm...I don't want to rain on any parades, but I'm just wondering why you didn't want to use Velocity, as it accomplishes the same thing and it's already written and well-supported? --doug --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click [INVALID FOOTER]
RE: [Mav-user] opt-freemarker
From: [EMAIL PROTECTED] [mailto:mav-user- [EMAIL PROTECTED] On Behalf Of Eelco Hillenius So, I hereby vote +1 for write access for Ed Ward. What about the other developers? I'm +1. (I just got back from a long vacation, it'll take me a while to catch up on these threads) Jeff --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click [INVALID FOOTER]
Re: [Mav-user] a new view
It sound nice. I use Velocity mostly, and am still very content with it.
But, Velocity would not be useful for you as it does not provide you with
valid XML source files. Just wondering... what kind of stuff are you doing
with these XML input files?
Eelco
- Original Message -
From: Joseph Dane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, August 27, 2004 8:21 PM
Subject: [Mav-user] a new view
I recently had reason to develop a new view type for Maverick, and
wonder if there might be any interest in it. If so, perhaps I can
contribute it back to the project.
The problem: I needed a very simple X?HTML template system. It had to
be something that, however, complicated under the hood, could be used
by junior developers and design people. I also wanted the source
pages to be valid XML, so that I could use the various XML tools to
edit/process/test the pages.
I wanted to avoid JSP's scriptlet syntax. JSTL might work, but I
wanted the source pages to be valid XML, so I wanted to avoid stuff
like
a href=c:out value='...'/ ... /a
Basically, I wanted XML source files, with the ability to dynamically
evaluate expressions and a some minimal amount of flow control.
Looping, for sure. Conditionals, probably. Something to match the
minimalist spirit of Maverick itself.
Something that might look like this (with some of the namespace stuff
cleared away):
html
body
h2Welcome ${user.fullName}/h2
Your order contains the following items:
table
ctl:for-each items='${order.items}' name='item'
trtd${item.productId}/tdtd${item.description}/td/tr
/ctl:for-each
/table
the current time is ${util.dateTime}
/body
/html
looks a bit like JSTL, but is required to be valid XML, unlike
JSP+JSTL. I used OGNL for the expression language.
The processing model goes like this: the page description (e.g. the
above sample) is loaded once at app startup and parsed as a stream of
SAX events. The events are recorded, and we do a certain amount of
pre-processing, e.g. joining and compiling text nodes. Then, at
request time we replay the event stream using a request specific
evaluation context that contains things like the current request,
the authenticated user, and some utilities. Maverick makes this
pretty simple, because we can grab the next transform step in the
view handler, and send the replayed SAX events on down the line.
This means that any XSTL we might want to perform can be specified in
Maverick's config, and will be handled completely by Maverick.
Another nice thing about this is that unlike using JSP+XSLT, where
the output of the JSP has to be re-parsed on every request, in my
system the source is parsed exactly once.
The strange thing about all this is that I wasn't able to find
anything that quite suited my purpose. So I guess that's one purpose
of this message: to see what I may have missed in the sea of Java
webapp frameworks.
The other purpose is to see if there's any interest in this. If not,
then I must have missed something, because I've been quite pleased
with the results. If so, then I can see about getting it cleaned up
and put out somewhere for the Maverick community to have a look at.
--
joe
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
[INVALID FOOTER]
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
[INVALID FOOTER]
Re: [Mav-user] a new view
Doug Kirk [EMAIL PROTECTED] writes:
Hmmm...I don't want to rain on any parades, but I'm just wondering why
you didn't want to use Velocity, as it accomplishes the same thing and
it's already written and well-supported?
I do use Velocity, and am happy with it in the contexts in which I
use it.
However, it didn't seem to quite fit here. I wanted the source pages
to be plain old HTML, to the greatest extent possible. So consider
something like a role-sensitive navigation bar. rather than
#if ($user.inRole('admin'))
a href=''AdminFunctions/a
#end
#if ($user.inRole('manager'))
a href=''ManagerFunction/a
#end
...
I wanted
a href='' ctl:if='${user.inRole(admin)}'Admin Functions/a
...
Also, I wanted to be able to leverage XML tools (XSLT) in interesting
ways. If the control elements are expressed in XML, then I could
(for example) pass a template containing a looping construct through
an appropriate stylesheet (I'm referring here to an offline process)
and get a reasonable looking mockup.
Another thing: I figured I'd be using XSLT at runtime. Both JSP and
vanilla Velocity are what you might call text oriented. Meaning
that the results of a template evaluation or JSP page evaluation
would have to be reparsed as XML on every request. I wanted to avoid
that overhead.
Certainly I could have used Velocity. I'm not terribly proud of
having increased the number of Java web technologies, and I always
figured I could resist the urge when it came upon me. But it turned
out I was wrong.
--
joe
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
[INVALID FOOTER]
