Rickard �berg writes:
> 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.
The two are independant... explanation below.
> 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.
This is near identical to the process we use, except it's the webbie
who does the dummy stuff, not the techie. The webbie doesn't ever
have to talk to the techie; he just designs a web page with dummy data
which is marked as dummy 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
> :-)
That's the case using XMLC/DOM as well; when the html changes you just
recompile the html to a java class and use that class instead.
> 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.
Yes, I'm talking about a push model and you're talking about a pull
model, but the two are equally decoupled. In both of them the webbie
just puts in a tag which means 'dynamic data goes here'. In the push
model this tag is standard html, and in the pull model it is from some
user-defined taglib.
> 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.
I will do that (haven't yet... at the wrong machine). But I can
'show' you the method employed with XMLC here. Start with an html
page with just one dynamic link.
<Html>
<Head>
<Title>A dynamic link</Title>
</Head>
<Body>
<A href="http://somewhere.someplace.com/path" id="link_tag">
<Span id="link_text">A Link</Span>
</A>
</Body>
</Html>
Then compile that using XMLC to a java class, LinkPage.class
Now in your servlet you can manipulate the document:
/* Some classes we need */
import org.w3c.dom.*;
import org.w3c.dom.html.*;
LinkPage page = new LinkPage(); // Create a new instance of the page
HTMLAnchorElement link_tag = (HTMLAnchorElement)page.getLink_tagElement(); // Get a
ref to the anchor tag
link_tag.setHref( "http://somewhere.else.com/another_path" ); // Set the anchor href
HTMLElement link_text = (HTMLElement)page.getLink_textElement(); // Get a ref to the
span tag
link_text.removeChild( link_text.getFirstChild() ); // Remove the dummy text that was
in there
Document doc = link_text.getDocument(); // Get a ref to the org.w3c.dom.Document for
this page
Text new_link_text = doc.createTextNode( "Some link text" ); // Create a new text node
link_text.appendChild( new_link_text ); // Append the new text node under the span tag
request.getWriter().println( page.toDocument() );
Neat, huh? This removes the webbie having to know _anything_ about
how the dynamic content is generated. No custom taglibs, no inline
code, nothing. All he's got to know is that, where something needs to
be dynamically generated he puts a <span id=...> tag and where he
wants a tag to be dynamically modifiable he gives it and id
attribute. So long as these ids remain consistent throughout the page
then it doesn't matter how the structure of the page changes.
I'm not saying that jsps are inherantly evil; I'm saying here's a neat
way of doing it which I like.
Tom
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
