On 8/8/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Craig McClanahan wrote: > > And you were so ***good*** about the Maven thread! :-) :-) :-) > > You can't expect me to turn around all at once can you Craig?!? :) LOL >
:-) > You know, I started making this a reply to that thread because I didn't > think it would go any further, and I originally said if it did then I'd > start a new thread... but, as I was typing my response I started to > realized is probably *would* go a message or two more, so better to > start that new thread now :) > > > Regarding stylability, the JSF standard components basically adopted a > > common convention from the Struts tags, in that they all sport a > > "styleClass" and a "style" attribute. The former is essentially a > > passthrough to the HTML "class" attribute (you can't use that directly > > in JSP because of the way JavaBeans property names work ... getClass() > > is inherited from java.lang.Object so you can't have a JSP attribute > > named "class"). In a similar way, the "style" attribute value, if > > specified, is passed through directly. > > Hmm, interesting. Don't think I knew that. > > > <snip> > > Lots of info there :) > > I'm going to have to play a bit... my concern, which you probably could > guess, is that in using JSF I may be giving up a lot of freedom in terms > of page design. Or, more likely the case, making it more difficult to > get the same results. > > I'm finding that I'm something of an anomoly (like you needed me to tell > you that!) in that I like doing page development at least as much as > server-side coding. I like the creative and visual feedback you get, > and I like pushing boundaries with CSS and layout. I'm thinking that > JSF might make that tougher to do. It sounds like to get the level of > flexibility I'd like to have would really require me developing my own > components, at which point I have to start asking myself if it's worth > it... I know there are other benefits to JSF, but at the end of the day > if I can't produce the visually attractive apps I'm known at work for > delivering that ALSO fulfill the business needs well, and doing so in at > worst the same amount of time it takes now, it's probably not justifiable. In one respect, at least, you are not an anomaly (although over time I think you'll end up in the minority). There is a creative tension in web page design between those who want to use raw HTML coupled with a few markers for dynamic content -- think Tapestry or Velocity for classic examples -- and those who want their component framework to deal with *all* the issues (at the flexibility cost of not allowing raw HTML markup at all). JSF as a technology doesn't dictate one approach or the other -- it enables both. However, 1.0/1.1 didn't do a good enough job on the first case (intermixed template text and JSF component tags), leading to some justified knocking on that regard. We simply didn't have time to get it all done. Fortunately, JSF 1.2 is going to deal with a bunch of those interoperatbility issues. With regard to the second approach, given a sufficiently rich component library, you'll never miss the "flexibility" to include raw HTML. (I'm one of those folks who, when writing static HTML pages, prefers coding raw HTML in a text edtior. In 1998, I was normal. In 2005, I am wierd :-). GIven a sufficient diversity of libraries, the "inflexibility" of a component library just won't matter any more, in the same way that it would be silly, in an interview, to ask a graphic designer to describe all the possible esoteric attributes that are legal on an HTML <select> tag. That's what IDEs are for -- to let people who *don't* understand all the nitty gritty details still be productive. And, in software design, that's what components are for -- to let people who are not O-O gurus be productive. And even O-O gurus need to do prototypes once in a while ... it's nice to have component frameworks around for those use cases :-). Craig PS: The other side of "raw HTML" is that HTML is not the only markup language in use. Wouldn't it be nice if your component was able to detect "AHA! I'm being rendered on a mobile device that uses WML instead of HTML" and does the right thing? Try *that* with a Struts HTML tag :-). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
