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?
> 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?
> 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.
> 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. 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.
> 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?
> 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 :-)
regards,
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]
