Re: Newbie Question: Are HTML attributes always stripped for tables?

Jacob Lauemøller <[email protected]>
Newsgroups gmane.comp.java.enhydra.barracuda.general
Message-ID <[email protected]>
Hi,

Thanks for your input!

Embedding directives in the HTML page makes it hard to read, but more 
importantly also assumes ownership of the class attribute. How does that work 
with pages using CSS? Keeping the directives in a separate file certainly is 
a workable solution, but it as I see it, the downside is that it increases 
the complexity of my project (because I now have one more file per HTML page 
to update and keep in sync.) 

Each to his own, I guess, but to me it would have been much more useful if the 
components respected the formatting used in the HTML and provided a closer 
approximation to a direct use of XMLC. Who knows, perhaps both approaches can 
co-exist?

As I said, I'll take the template approach for a spin, but flexible as it may 
be, I don't find it nearly as attractive as having smarter components.

Cheers,
Jacob

On Tuesday 12 August 2003 15:09, Diez B. Roggisch wrote:
> Hi,
>
> >Ok, this was sort of what I had figured out from reading the documentation
> >etc. and looking at the source. Just wanted to make sure. I will give the
> >template approach a spin but personally do not like have directives in the
> >HTML page (I'm aware that I can keep a separate mapping file but in my
> > opnion this seems to result in a more brittle application and somewhat
> > dilutes the non-intrusive approach that makes XMLC so attractive.)
>
> Well, that might be a matter of taste - but actually you'll have to
> provide some sort of  coupling between html and the code. I agree that
> it would sometimes be nice to have some sort of compiletime validation
> here, that ensures that for example a template model and the xmlc-class
> used to bind match. But so far nobody came up with a solution to that,
> neither in barracuda nor in any other web-developement framework I know
> (e.g struts, zope).
>
> >It would seem to me that BTable could have used default attributes (i.e.
> > none) for the columns not defined in the HTML and then simply retain any
> > attributes specified for the defined columns. This would have been more
> > in line with how I would have coded an XMLC-only approach; cloning the
> > existing row and substituting values into it.
> >
> >So, I could have
> >
> ><html>
> >   ...
> >   <table id="resultTable">
> >      <tr>
> >         <td id="columnA" align="center">Column A</td>
> >         <td id="columnB" align="right">Column B</td>
> >      </tr>
> >   </table>
> >
> ></body>
> >
> >TableModel could then have had a method
> >
> >   Object getValueAt(int row, String column)
> >
> >which would have worked, in my opinion, just as well (with the provision
> > that the table fill is not HTML driven rather than model driven.)
>
> Your approach still  depends on non-xmlc-managed, html driven and loosely
> coupled data. I don't see the advantages here. There have been attempts to
> make the BTable layout controlled by the underlying html - but I never
> heard of that again. Even if you did it - it won't be less error-prone and
> complicated that the BTemplate. But maybe you surprise me :)
>
> Regards,
>
> Diez
>
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.