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

Hi Jacob,

At 04:23 PM 8/12/2003 +0200, you wrote:
>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?

There is no problem with directives and CSS.  For instance, here is a 
directive + css class before processing....

<span class="Dir::Get_Data.SomeModel.modifyTextKey someCSSClass 
anotherCSSClass">blah</span>

...and here it is after processing...

<span class="someCSSClass anotherCSSClass">modified text</span>

As you can see, specified CSS classes are left intact, so there is no 
problem with mixing directives and CSS class names.  Furthermore, since 
embedded directives don't affect the validity of the markup like other 
templating languages, it doesn't affect the class attribute's functionality 
even if the directive isn't processed.  It is all perfectly compatible with 
existing standards.  It just occurred to me that you might not have known 
that you can have multiple CSS class names in the class attribute.  Yup, 
you can.  Multiple CSS class names may be supplied in a space-separated 
manner which, obviously, provides all the functionality we need to mix 
directives with CSS class names.

>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.)

I tend to have a single external file with all my id --> directive mappings 
for a common set of markup files.  No need for a separate directives file 
for every markup file.  Plus, you can then modify the directives without 
ever touching the markup files.  This is especially beneficial if you have 
common directives in multiple markup files.  I see this as a great 
advantage.  It actually reduces maintenance rather than increasing it.

>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?

Well, it isn't entirely up to the components.  They just keep store 
information.  The component renderers are where you need to look for 
respecting existing formatting and such.  BTable is actually improved from 
its previous functionality since Denny Chambers modified it to better 
support the html table spec better.  That said, there is no reason it 
couldn't be improved upon even more.  Keep in mind that components like 
BTable fell to the wayside after it became apparent just how powerful 
BTemplate could be.  If you think BTable, BList, or any other component 
(and/or renderer) could use some tweaking, I encourage you to make it work 
the way you want and then supply a patch which we'd certainly consider 
applying.

>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.

Thanks for the feedback and, hopefully, for the help in improving the 
components and their renderers!

Jake

>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
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda