Hey
Offtopic, skip if you want.
I don't think we're getting much more in this discussion regarding
right/wrong/better/worse, but at least it's clarifying :-)
Tom Cook wrote:
> 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 see. Yup, huge brick being thrown ;-)
> 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.
I see. So, but all the Java code controllers need to know what HTML page
they're being used in, right? Or is it possible to apply two different
HTML pages to the same controller depending on where in the site the c.
is being used? To me this is a good test of whether the V and C are
coupled or not.
> > > 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.
Hold on here. In my model the view is completely dumb too in the sense
that it doesn't *do* anything. It just extracts data from the
controller. If you replace the view with another one there is no
functionality lost.
> 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.
You are coupling the controller to the structure of the view, whereas I
am coupling the view to the structure and content of the controller
result data. Neither is "tighter" I think (although I still want to see
how you can apply multiple views to the same controller in your model),
but since the view is easier to change (just change JSP page) I prefer
that solution.
> 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.
Well, first of all I might be spoiled with slightly more intelligent
webbies, but anyway ;-)
All the webbie has to know is the structure of the output data from the
controller. And this knowledge can be expressed in JavaDoc, or similar.
I have also made a component that lets the webbie introspect the
controllers result data so that he can actually use the output without
having to talk to the techie at all.
Also, the tags that the webbie has to know are extremely few. Most of
the work can be done with "iterator" and "get property". It doesn't take
*that* long time to show these to a webbie, even though they may only
have "HTML for Dummies" on their shelf ;-)
> > How does iterators work?
>
> Iterator iter = enum.iterator();
> while( iter.hasNext() )
> {
> ...
> }
This needs more explanation. How does the webbie convey in the HTML that
"loop this table row".
E.g. in my model I would do something like:
<TABLE>
<webwork:iterator name="people">
<TR><TD><webwork:property name="name"/><TD><webwork:property
name="email"/></TR>
</webwork:iterator>
</TABLE>
How is that conveyed in your stuff? And what does the code to fill it in
look like?
> 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,
Hehe.. a lot of models "work", but we have higher requirements than
that, right? ;-)
Interesting discussion :-)
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]
