Hi!
Tom Cook wrote:
> No, the way we use XMLC is to compile the html to a java class (well,
> it treats it as xml with the html dtd, but this is more-or-less html)
> and then use the w3c DOM to insert/remove bits. Then the class
> produces an html document when you ask for it.
>
> This means that the webbie can produce html pages with dummy data in
> them which look exactly like the end product without dynamic bits.
> Then that it approved by management/whoever. Then we take the dummy
> pages, XMLC them and write code which replaces the dummy data with our
> dynamic data. That way prototypes aren't throw-away any more, they
> are what you use in your final site.
Hehe... well, my model is even better then :-) Your process is a 2-step
one: first webbie creates template with dummies, then techies replace
dummies with real values. This is a very common model, and one that I've
used myself on a number of occasions. The problem, as we all know, with
that is how you deal with changes to the template once the techies have
done their part. Non-trivial in most cases.
My process is a 1-step: webbie and techie decide together how the page
will look like and what the dynamic contents will be. The techie then
produces JavaBeans which return dummy values, and the webbie creates the
HTML that through taglibs accesses these values. BOOM. Now you have a
working app, and the time it took you to do it was close to zero. The
values may be dummy ones, but there is no change to the HTML/JSP from
this point. When the techie has updated the JavaBeans to really use the
backend data store it just works. And you can gradually see the site
come alive as he updates the JavaBeans to get real data.
But that's not all: in the meantime the webbie can work in parallel to
upgrade the HTML with nicer fonts and colors and images and whatnot.
Since the two tasks are completely decoupled they can't break each
others work. So, you have a working protoype from day one which then
evolves both techie wise and webbie wise. Absolute nirvana if you ask me
:-)
Of course, you *can* still use the 2-step model with HTML templates
including dummy values, but I would rather call that "sketches" than
"prototype".
> > So, JSP != "Java code in HTML". Can be, but don't have to be.
>
> Alright, maybe I was a bit strong on that one. But I still think XMLC
> provides a cleaner mechanism for separating the job of the developer
> and the web designer. They never need to edit each other's files.
But the techie needs to know the structure of the webbies work. So, if
the webbie decides to restructure the page you're in trouble. Also, what
if the webbie decides that the logic you do should be usable in several
different pages in different ways (i.e. using subsets of the retrieved
data for example). From what I have seen of XMLC and all other Model-2
frameworks the control JavaBeans always know about the structure the are
going to be put in. They "push" data, whereas in my model the data is
"pulled" by the view.
But I talk too much. Much easier to show you, and you can make up your
own mind if I talk gaga or not. :-) Download the first version of the
EBS system I'm working on right now from:
dreambean.com/download/rickard/EBS-0.1.zip
Look in /resources/view to find an example of what I'm talking about.
The JSP's use three mechanisms: a model-2 dispatcher to invoke
JavaBeans, a simple taglib to extract data from the JavaBeans into the
page, and jsp:include to make the whole thing component oriented.
Put ebs.war in Tomcat and ebs.jar in jBoss. Run Tomcat and jBoss, surf
to /ebs to view application.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
