Struts list regeneration problem

[Suresh Metla]

Hi All,
When i am submitting a page which holds a list of objects, this list is not
getting populated in form object.
In form object i am holding data as an arraylist of objects and I
am populating a series of rows in JSP using struts nested:iterate tag over
the array list. But when i am submittting the page the arraylist is always
getting intialized to the new arraylist. it is not able to generate list of
objects from JSP/HTML page. Is there any round about to solve this problem.
Please let me know, is it possible to regeneate List of objects that are
displayed in JSP using Iterator tag?

-Thanks,
Suresh.

*Code*
Form :
**
*private* ArrayList regionList = *new* ArrayList();

JSP:

   <nested:iterate name ="sureshTestForm" property ="regionList" id="region"
indexId="i"
    type ="com.test.Region">
    <tr class=accent>
     <td width="05%"><html:checkbox name="region"
property="markedForDeletion"/></td>
     <td width="10%"><test:stateoptions name="region"
property="stateId"/></td>
     <td width="32%"><html:text name="region" property="zip"/></td>
     <td width="10%"><html:text name="region" property="radius"
maxlength="5"/></td>
     <td width="20%"><test:locationoptions name="region"
property="locationId"/></td>
    </tr>
   </nested:iterate>

[ggb7]

Hi,
I am getting seriously involved with Struts and have 2 questions
related to choosing either s1 or s2?

- For a new project, which I would like to eventually move it to JSF?
- For the job market, which one is in higher demand?
thanks much!
gaétan



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Antonio Petrelli-3]

2007/8/7, ggb7@... <ggb7@...>:
> - For the job market, which one is in higher demand?

It depends on the nation, I suppose.
In Italy, there are lots of requests for Struts 1 (in fact they still
call it "Jakarta Struts", and Struts 1.1 is still in use, poor Italy
:-) )

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Piero Sartini-3]

> - For a new project, which I would like to eventually move it to JSF?

choose the technology (component based or action based) before choosing the
framework.

if you want to go for a component based approach like JSF then choose a
framework like Apache Shale or JBoss Seam. Even VWP may be considered a
framework (and allows nice gui editing).

if you decide to go with an action based framework, you should come back to
the question s1 or s2... personally, I would go with s2.

Piero.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Frank W. Zammetti]

Not just poor Italy... my experience has been that this isn't uncommon in
the United States either, and anecdotally in other countries as well... in
fact, I'm willing to say that S1 usage, and even 1.1 usage, is still the
most common Struts usage world-wide.

Dunno where it'll be a year from now of course... I work in the finance
sector, and things tend to move a bit slower there than other sectors
might, but I don't know if that's typical of all sectors or not.

If I was starting a new project today and had a choice (but it had to be
Struts), I'd go with S2.  I find it, generally speaking, to be more
logical in how things work... simple things like attributes of tags and
config files being named in a meaningful way helps a lot.

Then again, if I *really* had my druthers, I'd use DWR for everything on
the back-end and pick best-of-breed widgets on the UI to construct my own
client-side framework... the last project I did more or less did this,
although we used S1 and not DWR, but it worked out tremendously well, so
in my mind the approach is more than sound, it's close to ideal...
standard enough that a decent developer can get up to speed quick, but
custom enough to fit the problem domain like a glove.

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@...
Author of "Practical Ajax Projects With Java Technology"
 (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
 (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
 Supplying the wheel, so you don't have to reinvent it!

On Tue, August 7, 2007 2:07 pm, Antonio Petrelli wrote:

> 2007/8/7, ggb7@... <ggb7@...>:
>> - For the job market, which one is in higher demand?
>
> It depends on the nation, I suppose.
> In Italy, there are lots of requests for Struts 1 (in fact they still
> call it "Jakarta Struts", and Struts 1.1 is still in use, poor Italy
> :-) )
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Rajam T.]

Hi,

You need to have a getter and setter for the id you have given to the iterate tag in the form bean. The return type of the getter method should be the type of object you have inside the arraylist. This way you can retrieve the arraylist. One more point to be noted is all the tags like <html:text> which comes inside the iterate tag should have the attribute "indexed" set to true. Only then the getter and setter in the form bean will work

Thanks & Regards

Rajam Thirunavukkarasu
-----Original Message-----
From: Suresh MKVS [mailto:suresh.metla@...]
Sent: Tuesday, August 07, 2007 10:02 PM
To: user@...
Subject: Struts list regeneration problem

Hi All,
When i am submitting a page which holds a list of objects, this list is not
getting populated in form object.
In form object i am holding data as an arraylist of objects and I
am populating a series of rows in JSP using struts nested:iterate tag over
the array list. But when i am submittting the page the arraylist is always
getting intialized to the new arraylist. it is not able to generate list of
objects from JSP/HTML page. Is there any round about to solve this problem.
Please let me know, is it possible to regeneate List of objects that are
displayed in JSP using Iterator tag?

-Thanks,
Suresh.

*Code*
Form :
**
*private* ArrayList regionList = *new* ArrayList();

JSP:

   <nested:iterate name ="sureshTestForm" property ="regionList" id="region"
indexId="i"
    type ="com.test.Region">
    <tr class=accent>
     <td width="05%"><html:checkbox name="region"
property="markedForDeletion"/></td>
     <td width="10%"><test:stateoptions name="region"
property="stateId"/></td>
     <td width="32%"><html:text name="region" property="zip"/></td>
     <td width="10%"><html:text name="region" property="radius"
maxlength="5"/></td>
     <td width="20%"><test:locationoptions name="region"
property="locationId"/></td>
    </tr>
   </nested:iterate>

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Ted Husted]

On 8/7/07, Frank W. Zammetti <fzlists@...> wrote:
> Then again, if I *really* had my druthers, I'd use DWR for everything on
> the back-end and pick best-of-breed widgets on the UI to construct my own
> client-side framework... the last project I did more or less did this,
> although we used S1 and not DWR, but it worked out tremendously well, so
> in my mind the approach is more than sound, it's close to ideal...
> standard enough that a decent developer can get up to speed quick, but
> custom enough to fit the problem domain like a glove.

+1

My team did our last project using the same sort of architecture, but
since the backend was on .NET, we used Jayrock instead of DWR. Works
great, and it also seems like the ideal mix to me. We had to roll our
own solution for the server-side validation and type conversion, but
we based that work on a chain of command, and it's layered so we can
reuse it with multiple front end applications.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Asthana, Rahul]

Hi Ted/Frank,
Is there a more detailed post/article that you have done regarding this architecture?
Thanks
Rahul

-----Original Message-----
From: ted.husted@... [mailto:ted.husted@...]On Behalf Of Ted
Husted
Sent: Wednesday, August 08, 2007 12:27 PM
To: Struts Users Mailing List
Subject: Re: struts1 or struts 2?


On 8/7/07, Frank W. Zammetti <fzlists@...> wrote:
> Then again, if I *really* had my druthers, I'd use DWR for everything on
> the back-end and pick best-of-breed widgets on the UI to construct my own
> client-side framework... the last project I did more or less did this,
> although we used S1 and not DWR, but it worked out tremendously well, so
> in my mind the approach is more than sound, it's close to ideal...
> standard enough that a decent developer can get up to speed quick, but
> custom enough to fit the problem domain like a glove.

+1

My team did our last project using the same sort of architecture, but
since the backend was on .NET, we used Jayrock instead of DWR. Works
great, and it also seems like the ideal mix to me. We had to roll our
own solution for the server-side validation and type conversion, but
we based that work on a chain of command, and it's layered so we can
reuse it with multiple front end applications.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Frank W. Zammetti]

Not specifically, no... although, both of my books go into this sort of
thing, and the first one includes a DWR-based project.

I'm also in the midst of a third book which will very definitely cover
this topic in detail right lots of practical examples... due out in,
roughly, this coming January.

Frank

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@...
Author of "Practical Ajax Projects With Java Technology"
 (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
 (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
 Supplying the wheel, so you don't have to reinvent it!

On Wed, August 8, 2007 12:58 pm, Asthana, Rahul wrote:

> Hi Ted/Frank,
> Is there a more detailed post/article that you have done regarding this
> architecture?
> Thanks
> Rahul
>
> -----Original Message-----
> From: ted.husted@... [mailto:ted.husted@...]On Behalf Of Ted
> Husted
> Sent: Wednesday, August 08, 2007 12:27 PM
> To: Struts Users Mailing List
> Subject: Re: struts1 or struts 2?
>
>
> On 8/7/07, Frank W. Zammetti <fzlists@...> wrote:
>> Then again, if I *really* had my druthers, I'd use DWR for everything on
>> the back-end and pick best-of-breed widgets on the UI to construct my
>> own
>> client-side framework... the last project I did more or less did this,
>> although we used S1 and not DWR, but it worked out tremendously well, so
>> in my mind the approach is more than sound, it's close to ideal...
>> standard enough that a decent developer can get up to speed quick, but
>> custom enough to fit the problem domain like a glove.
>
> +1
>
> My team did our last project using the same sort of architecture, but
> since the backend was on .NET, we used Jayrock instead of DWR. Works
> great, and it also seems like the ideal mix to me. We had to roll our
> own solution for the server-side validation and type conversion, but
> we based that work on a chain of command, and it's layered so we can
> reuse it with multiple front end applications.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Paul Benedict-2]

I have "JavaScript, DOM Scripting and Ajax Projects" -- good book for people
who want to get into AJAX.

On 8/8/07, Frank W. Zammetti <fzlists@...> wrote:

>
> Not specifically, no... although, both of my books go into this sort of
> thing, and the first one includes a DWR-based project.
>
> I'm also in the midst of a third book which will very definitely cover
> this topic in detail right lots of practical examples... due out in,
> roughly, this coming January.
>
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@...
> Author of "Practical Ajax Projects With Java Technology"
> (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
> (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
>

[Frank W. Zammetti]

Thanks Paul... The envelope is in the mail! <wink-wink/>

:)

Frank

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@...
Author of "Practical Ajax Projects With Java Technology"
 (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
 (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
 Supplying the wheel, so you don't have to reinvent it!

On Wed, August 8, 2007 2:03 pm, Paul Benedict wrote:

> I have "JavaScript, DOM Scripting and Ajax Projects" -- good book for
> people
> who want to get into AJAX.
>
> On 8/8/07, Frank W. Zammetti <fzlists@...> wrote:
>>
>> Not specifically, no... although, both of my books go into this sort of
>> thing, and the first one includes a DWR-based project.
>>
>> I'm also in the midst of a third book which will very definitely cover
>> this topic in detail right lots of practical examples... due out in,
>> roughly, this coming January.
>>
>> Frank
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>> AIM/Yahoo: fzammetti
>> MSN: fzammetti@...
>> Author of "Practical Ajax Projects With Java Technology"
>> (2006, Apress, ISBN 1-59059-695-1)
>> and "JavaScript, DOM Scripting and Ajax Projects"
>> (2007, Apress, ISBN 1-59059-816-4)
>> Java Web Parts - http://javawebparts.sourceforge.net
>> Supplying the wheel, so you don't have to reinvent it!
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Asthana, Rahul]

Thanks Paul and Frank for the books.
I used some AJAX in a project, and I had made a mental note to myself(though I dont remember why,exactly, hehe) that for data calls that do not change the content of the page => ajax.For calls that may result in the way a page can be rendered => new left nav, new tables , new html elements etc..=>go to UI controller\ servlet or whatever.
Besides,I was also interested in how things like workflow are handled in an "AJAX based framework", as opposed to a webapp that "happens to use" AJAX .

-----Original Message-----
From: Frank W. Zammetti [mailto:fzlists@...]
Sent: Wednesday, August 08, 2007 2:13 PM
To: Struts Users Mailing List
Cc: Struts Users Mailing List
Subject: Re: struts1 or struts 2?


Thanks Paul... The envelope is in the mail! <wink-wink/>

:)

Frank

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@...
Author of "Practical Ajax Projects With Java Technology"
 (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
 (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
 Supplying the wheel, so you don't have to reinvent it!

On Wed, August 8, 2007 2:03 pm, Paul Benedict wrote:

> I have "JavaScript, DOM Scripting and Ajax Projects" -- good book for
> people
> who want to get into AJAX.
>
> On 8/8/07, Frank W. Zammetti <fzlists@...> wrote:
>>
>> Not specifically, no... although, both of my books go into this sort of
>> thing, and the first one includes a DWR-based project.
>>
>> I'm also in the midst of a third book which will very definitely cover
>> this topic in detail right lots of practical examples... due out in,
>> roughly, this coming January.
>>
>> Frank
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>> AIM/Yahoo: fzammetti
>> MSN: fzammetti@...
>> Author of "Practical Ajax Projects With Java Technology"
>> (2006, Apress, ISBN 1-59059-695-1)
>> and "JavaScript, DOM Scripting and Ajax Projects"
>> (2007, Apress, ISBN 1-59059-816-4)
>> Java Web Parts - http://javawebparts.sourceforge.net
>> Supplying the wheel, so you don't have to reinvent it!
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Ted Husted]

On 8/8/07, Asthana, Rahul <Rahul.Asthana@...> wrote:
> Besides,I was also interested in how things like workflow are handled in an "AJAX based
> framework", as opposed to a webapp that "happens to use" AJAX .

Conventional web applications tend to use a different page for each
top-level view. If we are using a tab-motif, each tab is usually a
separate (thin) page. In an AJAX application, each tab is often a
separate div of the same (rich) page, and we make the appropriate div
visible or invisible.

In a conventional web application, workflow means bouncing between
thin pages, and trying to maintain state as we go. In an AJAX
application, we tend to bounce between divs on the same rich page. A
very handy difference is that we can store state on the client-side as
JavaScript variables. Another big difference is that we don't have to
resort to gizmos like Tiles and SiteMesh to retain look and feel.
Instead of swapping page fragments between requests, we can swap divs
progmatically.

Of course, we've been trying to simulate this approach in thin pages
for years. I can remember doing the same sort of thing in Perl eons
ago. We would output the base page, switch to the panel to insert for
a given request, and output the rest of the base. Conventional ASP.NET
does the same sort with its panel control. The difference is that with
AJAX it is not a simulation. It's the real thing. The client is
actually changing the content in the middle of the page.

The very best part is that the AJAX architecture creates a very clear
separation between model and view. In a conventional web application,
we tend to muddle the action workflow with the concerns of both the
model and the view. In an AJAX application, it's much easier to keep
all of the model concerns on the server-side of a JSON request, and
keep all the the view concerns client-side.

IMHO, if we had today's JavaScript/CSS/HTML environment available to
us in 1998, then JSP, ASP, JSF, PHP, and all the rest of it, would not
exist. We did all these things to make up for the shortcomings of the
client-side environment, and, since then, the key shortcomings have
been addressed.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Frank W. Zammetti]

On Thu, August 9, 2007 8:24 am, Ted Husted wrote:
> IMHO, if we had today's JavaScript/CSS/HTML environment available to
> us in 1998, then JSP, ASP, JSF, PHP, and all the rest of it, would not
> exist. We did all these things to make up for the shortcomings of the
> client-side environment, and, since then, the key shortcomings have
> been addressed.

Great observation IMO, and it couldn't be more true.

I always like to tell the story of a Java users group I was at maybe two
years ago now... the speaker was talking about AJAX and he said that the
people who know what AJAX is at that point are the same people who are
pissed about it because frankly it hasn't been anything new for them for
some time!

I have one app that was put in production in 1998 ironically, the year you
picked here Ted, that you'd look at today and say it was AJAX, an RIA, but
it didn't use what we'd call AJAX now (hidden iFrame that got Javascript
back which executed upon return and automatically updated and hide and
showed a variety of DIVs on the page... in fact, this is the extreme case
because absolutely every view the user can ever see in the app is loaded
up front and never generated server-side, it's only data being plugged
into fields after startup).  If I'd have thought for one second that what
I was doing was any big deal, unusual in some way, it could have been my
name going down in history as having invented AJAX instead of Jesse James
Garrett!  And the worse part is I know I'm not the only one that can say
that! LOL

I've had the interesting experience of witnessing an evolution here at
work... in 1998, I was the only one building apps in that fashion at this
company, everyone else was very much at the other extreme, the whole "let
the server do everything" approach as you described, thin pages, etc.
Everyone thought I was nuts (I only got away with it because my projects
are always successful, something not everyone here can claim), I got into
some really heated dehates with folks over the years about it too.  Now,
things are very much swinging the other way... apps are being built now in
much more RIA ways, it's much more mainstream thinking.

I think that evolution is playing itself out across many organizations
now, and that's my point: there's a critical mass now, and the mindset is
starting to change, and Ted's right, many of the technologies we're
saddled with today would never have needed inventing if everyone had
listened to me (or the others that were doing what I did in various
orgamizations) back in 1998! LOL

> -Ted.

Frank


--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@...
Author of "Practical Ajax Projects With Java Technology"
 (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
 (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
 Supplying the wheel, so you don't have to reinvent it!

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Asthana, Rahul]

Hi Ted/Frank,
Well, The first project I did in the industry,(I was a trainee then) in 2000 was a full scale ajax(of course,we called it something else) project. Ajax was used out of compulsion.We had a gigantic user entry form with around 100 controls;which was divided into 5 tabs, which were actually layers/divs. It could not be one single page\form due to constraints of user experience; and it could not be five different jsps because the tabs had inter-related field validation rules.
We used ajax for populating dependendent combo boxes and showing error messages based on server side validations.It did not make sense to post the whole gigantic form for showing an error message.I still dont see how we could have done that without ajax.The challenges were kind of similar to DOJO users of today.Large javascript files made the pages heavier to load.
Otherwise, it worked out quite well.
By the way, have any of you done any performance metrics on an ajax based implementation vs a non ajax based one?
rgds
Rahul

-----Original Message-----
From: Frank W. Zammetti [mailto:fzlists@...]
Sent: Thursday, August 09, 2007 10:25 AM
To: Struts Users Mailing List
Cc: Struts Users Mailing List
Subject: Re: struts1 or struts 2?


On Thu, August 9, 2007 8:24 am, Ted Husted wrote:
> IMHO, if we had today's JavaScript/CSS/HTML environment available to
> us in 1998, then JSP, ASP, JSF, PHP, and all the rest of it, would not
> exist. We did all these things to make up for the shortcomings of the
> client-side environment, and, since then, the key shortcomings have
> been addressed.

Great observation IMO, and it couldn't be more true.

I always like to tell the story of a Java users group I was at maybe two
years ago now... the speaker was talking about AJAX and he said that the
people who know what AJAX is at that point are the same people who are
pissed about it because frankly it hasn't been anything new for them for
some time!

I have one app that was put in production in 1998 ironically, the year you
picked here Ted, that you'd look at today and say it was AJAX, an RIA, but
it didn't use what we'd call AJAX now (hidden iFrame that got Javascript
back which executed upon return and automatically updated and hide and
showed a variety of DIVs on the page... in fact, this is the extreme case
because absolutely every view the user can ever see in the app is loaded
up front and never generated server-side, it's only data being plugged
into fields after startup).  If I'd have thought for one second that what
I was doing was any big deal, unusual in some way, it could have been my
name going down in history as having invented AJAX instead of Jesse James
Garrett!  And the worse part is I know I'm not the only one that can say
that! LOL

I've had the interesting experience of witnessing an evolution here at
work... in 1998, I was the only one building apps in that fashion at this
company, everyone else was very much at the other extreme, the whole "let
the server do everything" approach as you described, thin pages, etc.
Everyone thought I was nuts (I only got away with it because my projects
are always successful, something not everyone here can claim), I got into
some really heated dehates with folks over the years about it too.  Now,
things are very much swinging the other way... apps are being built now in
much more RIA ways, it's much more mainstream thinking.

I think that evolution is playing itself out across many organizations
now, and that's my point: there's a critical mass now, and the mindset is
starting to change, and Ted's right, many of the technologies we're
saddled with today would never have needed inventing if everyone had
listened to me (or the others that were doing what I did in various
orgamizations) back in 1998! LOL

> -Ted.

Frank


--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@...
Author of "Practical Ajax Projects With Java Technology"
 (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
 (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
 Supplying the wheel, so you don't have to reinvent it!

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Frank W. Zammetti]

Asthana, Rahul wrote:
> By the way, have any of you done any performance metrics on an ajax based implementation vs a non ajax based one?

Early on we did a proof-of-concept that did exactly this... what we
found was that the AJAX version was universally perceived as being
faster, even when a few cases actually weren't (i.e., client-side
processing took longer than the equivalent server-side version).

The conclusions we drew were:

1. You have to strive to minimize the amount of Javascript executing as
a result of each AJAX call.  There is a line that when crossed means the
server can actually render the whole page fresh and the browser can
display it faster than AJAX+Javascript updates.

2. There is a balance you need to strike between the number of AJAX
calls and size of each AJAX response... there is again a line that when
crossed means that X number of small AJAX requests takes more time than
one non-AJAX "transaction".

3. There is definitely tuning that needs to be done in terms of moving
static resources off to the web server, making sure your AJAX responses
are tight, things like that.  The very biggest impact we found, recently
actually, was in moving all images, CSS, Javascript and other static
content off to the web server... especially when your doing AJAX and
your making numerous small requests vs. one or two larger non-AJAX
requests, not having to hit the web server makes a huge difference...
remember that in most cases, there is a small number of connections
available between the web server and app server (we had 5 I believe)
even though you may have 100 connections/threads available on the web
server (and probably app server).  That's where we found the most
significant bottleneck... we're talking making an app twice as fast just
by moving static content off the app server!

4. Aside from the static content thing, this is the biggest point to
emphasize: you need to get your developers thinking a different way then
they probably are used to... they need to, for lack of a better way to
put it, trust the client more.  For instance, we had developers that
insisted on putting objects in session, even though myself and other
senior developers were telling them it'd be better to keep things in
Javascript objects client-side... they would tell you now we were 100%
right :)  This isn't a criticism of them though, when your used to doing
things a certain way, and they basically work well, you don't want to
change, especially given what many people have historically thought
about Javascript and client-side development.  But once you get the
mindset changing, you'll see a really huge improvement in performance of
your apps because the fundamental design leads to better performance
naturally.

> rgds
> Rahul

Frank

--
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@...
Author of "Practical Ajax Projects With Java Technology"
  (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
  (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
  Supplying the wheel, so you don't have to reinvent it!

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...