calendar widget @ irian.at

[Woodchuck <wo...@yahoo.com>]

hihi!

i went to your demo website (http://irian.at/myfaces/home.jsf) and
looked at the nice Calendar component example.

clicking on the elipse button "..." it opened up a very nice graphical
calendar box from which you can select any date in history.

i was just wondering, this calendar 'popup' has nothing to do with JSF
at all, right?  it's purely a javascript solution, right?

woodchuck


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

Re: calendar widget @ irian.at

[Sean Schofield <se...@gmail.com>]

> that calendar widget is driven from a .js file.  are you saying JSF
> produced that .js file much like how JSPs produce the associated .class
> files at run-time?

I haven't looked at the calendar component specifically.  If you are
seeing a reference to a js file that would not suprise me.  Many
components might rely on a js file when they can but still need to
generate a little dynamic javascript to call certain functions onclick
or whenever.

> 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

I agree that you want to limit the amount of javascript your component
generates.  There are various strategies for doing that including the
js file mentioned above.  I'm not an expert on faces yet so I am still
learning myself.

The tradeoff is that once you develop that nasty javascript, you can
reuse it over and over again just by dropping in the appropriate JSF
tags.  IMO its not the easiest thing keeping all of your js files
squared away and up-to-date either (which is what your alternative is
with not faces.)  The user of the calendar component (you) doesn't
have to worry about any of it as the component takes care of it for
you.




On Mon, 31 Jan 2005 19:35:28 -0800 (PST), Woodchuck
<wo...@yahoo.com> wrote:
> you're kidding.... right?
> 
> that calendar widget is driven from a .js file.  are you saying JSF
> produced that .js file much like how JSPs produce the associated .class
> files at run-time?
> 
> 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
> 
> even if localization is the reason, only those necessary specific parts
> need to be generated, the rest of the logic doesn't change... only the
> names of the months and any other words on that widget needs to be
> dynamic
> 
> am i understanding this correctly?
> 
> 
> --- Sean Schofield <se...@gmail.com> wrote:
> 
> > > i was just wondering, this calendar 'popup' has nothing to do with
> > JSF
> > > at all, right?  it's purely a javascript solution, right?
> >
> > Actually it has everything to do with JSF ;-)  It is a JSF component
> > that is generating all of that javascript for you!   Think of a
> > simple
> > JSP page.  In the end you get just HTML and javascript but there's a
> > whole lot of custom tags, etc. on that page that help you get there.
> >
> > > woodchuck
> >
> > sean
> >
> 
>                 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Find what you need with new enhanced search.
> http://info.mail.yahoo.com/mail_250
>

Re: calendar widget @ irian.at

[Sean Schofield <se...@gmail.com>]

> 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 have used Google Suggest before.  Its *very* impressive.

> Craig

sean

Re: calendar widget @ irian.at

[Craig McClanahan <cr...@gmail.com>]

On Mon, 31 Jan 2005 22:06:51 -0800 (PST), Woodchuck
<wo...@yahoo.com> wrote:
> 
> --- Craig McClanahan <cr...@gmail.com> wrote:
> 
> > On Mon, 31 Jan 2005 19:35:28 -0800 (PST), Woodchuck
> > <wo...@yahoo.com> 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

Re: calendar widget @ irian.at

[Woodchuck <wo...@yahoo.com>]

--- Craig McClanahan <cr...@gmail.com> wrote:

> On Mon, 31 Jan 2005 19:35:28 -0800 (PST), Woodchuck
> <wo...@yahoo.com> 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 

Re: calendar widget @ irian.at

[Craig McClanahan <cr...@gmail.com>]

On Mon, 31 Jan 2005 19:35:28 -0800 (PST), Woodchuck
<wo...@yahoo.com> 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.

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.

I'm sure glad that *I* don't have to create all the complicated JS and
DHTML logic necessary to pull that trick off.  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

Re: calendar widget @ irian.at

[Woodchuck <wo...@yahoo.com>]

you're kidding.... right?

that calendar widget is driven from a .js file.  are you saying JSF
produced that .js file much like how JSPs produce the associated .class
files at run-time?

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

even if localization is the reason, only those necessary specific parts
need to be generated, the rest of the logic doesn't change... only the
names of the months and any other words on that widget needs to be
dynamic

am i understanding this correctly?


--- Sean Schofield <se...@gmail.com> wrote:

> > i was just wondering, this calendar 'popup' has nothing to do with
> JSF
> > at all, right?  it's purely a javascript solution, right?
> 
> Actually it has everything to do with JSF ;-)  It is a JSF component
> that is generating all of that javascript for you!   Think of a
> simple
> JSP page.  In the end you get just HTML and javascript but there's a
> whole lot of custom tags, etc. on that page that help you get there.
> 
> > woodchuck
> 
> sean
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

Re: calendar widget @ irian.at

[Sean Schofield <se...@gmail.com>]

> i was just wondering, this calendar 'popup' has nothing to do with JSF
> at all, right?  it's purely a javascript solution, right?

Actually it has everything to do with JSF ;-)  It is a JSF component
that is generating all of that javascript for you!   Think of a simple
JSP page.  In the end you get just HTML and javascript but there's a
whole lot of custom tags, etc. on that page that help you get there.

> woodchuck

sean