--- 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?
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
>
> 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'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...
__________________________________
Do you Yahoo!?
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com
