On Mon, 31 Jan 2005 22:06:51 -0800 (PST), Woodchuck <[EMAIL PROTECTED]> wrote: > > --- Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > On Mon, 31 Jan 2005 19:35:28 -0800 (PST), Woodchuck > > <[EMAIL PROTECTED]> wrote: > > > > > [snip] > > > and isn't it generally bad to generate complicated javascript (or > > html > > > for that matter) from java code?... i can only imagine the > > maintenance > > > nightmare for this calendar widget if it is entirely "spat out" by > > some > > > java object having hard-coded javascript embedded within it > > > > On all the projects I've ever worked on, the primary objective is to > > meet the requirements of the functional spec for the application. > > That would seem somewhat more important than whether it invoves a lot > > of JavaScript or a little bit :-). > > > > Also, if I'm an application developer faced with a requirement that > > requires lots of JavaScript, I would ***much*** prefer that the pain > > of developing and debugging that JavaScript code be done, once, by > > the > > component developer, so that I can reuse that component on as many > > pages as needed -- without having to develop, tweak, or maintain that > > JavaScript myself. I've got more important things to work on. > > i agree. but let's say that component developer leaves the company. > now you're faced with having someone else maintain that nasty > component. is this a fair concern?
Sure it is ... but I'd have the same concern if the person who wrote a 5000 line JSP page that supported seven different input forms with scads of embedded scriptlets left the company. The advantage of a standard component API is that you probably *won't* have to write and maintain that component yourself -- you'll be able to acquire one from some commercial entity, from the open source community, or from internal development. That frees you (properly, IMHO) to focus on the application requirements instead of the plumbing. > > in my current contract, i had the fortune of inheriting unmaintanable > code. it was written so tight and abstracted that all of the main > pages shared the same few .jsp and Action sub-classes. even simple > changes would almost always result in some regression bug somewhere > else far away. it takes a lot of time to fix/enhance anything, and > more importantly, necessitates complete retesting because the generic > code has it's hand everywhere. > > i guess my point to this is, hard to maintain code is bad no matter how > you slice it. lol! what insight!! :D > Yep ... but that's not a reason to stick your head in the sand when the world is asking for webapps that behave more like rich clients :-). > > > > > When I was visiting with a JSF component vendor last fall, I saw a > > demo of a (commercial) JSF tree component where, in the demo app, the > > tree was backed by a database table with 6000 nodes in it. > > Obviously, > > that's not the sort of thing that you hard code into an HTML page > > :-). > > When the user opens a tree node, the client side code would do a > > background query to the server to retrieve just the data needed to > > update that part of the visual representation, and then dynamically > > updates the display, so no page refresh is required. > > please tell me how they did this. how is it possible to trigger server > side processing (from the client side), without submitting the page > (and then refresh the page with server side data just retrieved)? what > devilish trickery is this?!! > I don't know the precise technology this particular company used (it was a commercial component, after all), but I'd start looking at technologies like XmlHttpRequest. Google is your friend yadda yadda. The ability to ask the server for additional data in a background thread, coupled with the ability to dynamically modify the DOM in modern browsers, lets you do some very interesting things. (It's not at all JSF-specific, but creating JSF components that encapsulates this sort of functionality is going to be a *huge* win in the next couple of years.) Just to whet your appetite, try out Google Suggest, which dynamically refines its list of suggestions as you type each character of your search expression -- in a standard web application, with no plugin required. > > > > I'm sure glad that *I* don't have to create all the complicated JS > > and > > DHTML logic necessary to pull that trick off. > > me too > > > Yet, from the page > > author's perspective, it's just a JSF component, so it can be used > > exactly as easily as a "dumb" tree control that goes back to the > > server when a node is opened, and rerenders the entire page. > > > > Craig > > > > this reminds me of the ActiveX widgets of long ago... > Which also succeeded because they provided a standard API on top of which to innovate. Where would Java-based web applications be if everyone was building their own version of the servlet API? Craig
