Rickard �berg writes:
> Hi!
>
> Tom Cook wrote:
> > 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.
>
> No, I think there is a difference. Would it be possible in your model to
> wrap *a completely different HTML* page on top of the logic? I mean
> completely different structure, uses a subset of the first page's data,
> and so on. For example, if you use the same controller beans for WML it
> might not be a good idea to just "strip down the HTML". You might
> actually have to take away some data from the screen or restructure the
> app. With my "pull" version this is transparent as long as the
> controller JavaBeans can deliver the data needed for the most advanced
> case. In your "push" situation it seems to me like the controller knows
> the structure and layout of the view. Is this correct? If so, then how
> do you handle the above?
No, the controller does not know the layout of the view, but you are
correct, it is not possible to remove data from the page without
changing the controller. In effect I have rolled the controller and
view into one <duck the brick which is inevitably thrown>. I can
still completely rewrite the page, so long as there are the same id's
defined in tags in the page. If an ID is missing then it will break,
yes.
> > 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
>
> What if you want to put a "SimpleLinkPage" on top of this controller? I
> want to see that the controller can be "given" a page and fill in the
> data. In the above code your controller *knows* what the page is, which
> is bad.
>
> But it is more important than just being able to "skin" apps. The same
> controller may be used within the same app in just a slightly different
> way for another usecase. How is this supported?
>
> (Getting off-topic here)
>
> Also, this method seems to treat pages as single components. No good.
> That is very rare in my experience. More than often a page is
> constructed by several components (a header, a navbar, an input form, a
> result viewer, etc.) so the page needs to be easily deconstructed into
> smaller components that can be "plugged" together into a larger page. My
> model supports this through jsp:includes. Does this work for you too?
Yes, but in a slightly different way. We make Java code responsible
for generating all these subcomponents, and then only the structure of
the whole page is done in html. It is possible to compile
sub-components of the page into a class in the same was as the HTML
example above, then modify bits and put them into the main page; you
are simply making one DOM tree a child of a node in another. But we
don't usually bother with that; we usually just dynamically generate
all of the subcomponents.
> > 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
>
> And if there is no link? Again this seems to couple the code very
> tightly to the structure and layout of the result page.
In a way it does. It is making the view part of the MVC model
completely dumb, and forcing the controller to know exactly what the
view needs to know. But this decouples the view and the data in a way
in which yours does not. So one coupling is looser, the other is tighter.
> > 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?
>
> Uhm, no :-) For above reasons. In my model the code in a controller
> JavaBean does 3 things:
> * set() methods are called by dispatcher servlet for all incoming
> parameters
> * execute() is called by dispatcher servlet. Get all result data
> * get() methods are called as a result of the JSP page retrieving data
> from the JavaBean
>
> That's all. I don't have to know anything about HTML, XML, viewers or
> anything. Just "do the control thing". Heck, I can even reuse the same
> JavaBeans in a Swing GUI! :-) Now *that's* neat! And, to follow up on
> Trevor's concern, the JSP's I have done currently uses taglibs to
> extract the data, but it would be *perfectly possible* to put Java code
> in the JSP's to extract data instead. This might even be preferred for
> performance reasons in some cases.
>
> > This removes the webbie having to know _anything_ about
> > how the dynamic content is generated.
>
> True, but not the other way round. I prefer to let the webbie get the
> contents he wants, instead of letting the techie know how the page is
> structured.
The techie doesn't know anything about how the page is structured, he
just knows that he needs to insert data x at a place labelled y in the
page. There is no reference to the page structure.
Anyway, no matter which way you do it, either the webbie has to know
how the techie's stuff works or the techie has to know how the
webbie's stuff works. You can't decouple them completely, and it
seems to make sense for the techie to do the hard bits instead of
making the webbie (who, in my experience, has usually done a graphic
design course and has 'HTML for Dummies' on their shelf) learn more
stuff.
> What if you want to redesign the page completely later on?
> Then it is easier for the webbie to just move things around than to let
> the techie update the code to accomodate the new structure.
Yes. Except for that structure is irrelevant; it is the _data_
requirements that the techie needs to know about.
> > 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.
>
> How does iterators work?
Iterator iter = enum.iterator();
while( iter.hasNext() )
{
...
}
... but you knew that, right? ;-) The 'data bits' are generated by
the java code to some extent. Whether you actually generate the
entire table, or just duplicate rows in it or whatever, iteration is
done in java code.
> > 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.
>
> mm... perhaps.. give good answers to the above to convince me :-)
I'm trying, I'm trying. Maybe this way of doing things breaks the MVC
model a bit, and alright, that's not a good thing. But it works, and
it lets the webbie decide how it'll look and leaves the dynamic bits
up to the techie.
Tom
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
