RE: Newbie Question: Are HTML attributes always stripped for tables?
"Christian Cryder" <[email protected]>
| Newsgroups | gmane.comp.java.enhydra.barracuda.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Jacob, > I will give the template approach a spin but personally do not like > have directives in the HTML page...this seems to result in a more > brittle application and somewhat dilutes the non-intrusive approach > that makes XMLC so attractive.) Actually, the opposite is true (imo). If you don't have anything in the template (ie. pure XMLC approach via BTable, BList, etc), then you actually have a more-brittle application because the Java code that you write to manipulate the page MUST make assumptions about the structure associated with the ids it is manipulating. In other words, your code must know that you are dealing with a table, etc. And then if you go to change your structure to a list, or some different form, your code will immediately break. So the purpose of the BTemplate was actually to make it more flexible, by keeping the structure in the template and the java code just has to provide the data. Of course, this is not quite as "pure" in the sense that you do have some simple logic (iteration, directives) in the markup, but I think its ultimately a tradeoff worth making. IMO, creating BTemplate was the key "breakthough" in the Barracuda component model. Of course the beauty of Barracuda is that if you disagree you can still do it your own way. Try that in JSP ;-) > 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? Barracuda works fine with css (we use them extensively in our app). It interprets/strips the directives, and leaves the style sheet stuff. > 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 You are correct. We made this an option because some people wanted it, but in practice, we never use it for our apps here - we just embed the directives directly in the markup. I think the additional clutter is worth it because it does keep things simpler. My .02... Christian ---------------------------------------------- Christian Cryder Internet Architect, ATMReports.com Project Chair, BarracudaMVC - http://barracudamvc.org ---------------------------------------------- "Coffee? I could quit anytime, just not today" > -----Original Message----- > From: [email protected] > [mailto:[email protected]]On Behalf Of Jacob Lauemøller > Sent: Tuesday, August 12, 2003 8:23 AM > To: [email protected] > Subject: Re: [Barracuda] Newbie Question: Are HTML attributes always > stripped for tables? > > > 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 > > _______________________________________________ > Barracuda mailing list > [email protected] > http://barracudamvc.org/lists/listinfo/barracuda