Re: content management tool

[delbd]

Slide jakarta project does provide a struts based taglib to access content 
management :/

Le Lundi 18 Avril 2005 23:52, sudip shrestha a écrit :
> Just curious if there are any struts based content managment tools out
> there!
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
David Delbecq
Royal Meteorological Institute of Belgium

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Craig McClanahan]

On 4/18/05, Martin Cooper <[EMAIL PROTECTED]> wrote:

> To get beyond doing the grunt work yourself for Ajax, I recommend taking a
> look at this:
> 
> http://dojotoolkit.org/intro_to_dojo_io.html
> 
> and downloading the dojo.io package from their site.
> 
> Personally, I'm not convinced that we need anything new in Struts to make
> using Ajax easier. I'm building products today that make extensive use of
> the two technologies together, and haven't found a need to enhance Struts to
> do it. However, if we do add any Ajax (or Ajax-like) support to Struts, I
> want to be able to plug in my plumbing of choice (which would be Dojo right
> now) to get the most robust communication scheme available.
> 
> --
> Martin Cooper
> 

This is exactly the area I've been having trouble with this proposal
as well ... tell me again why you can't use Ajax techniques with the
standard Struts HTML tags?  If you can do it with handwritten HTML
pages (which you certainly can), you can also do it with existing
Struts HTML tags (or the standard JSF components, for that matter)
that offer attributes like "onchange" and "onclick" to plug in your
calls to JavaScript methods that do the actual background calls, and
then update the client side DOM of your page.

It seems to me that a framework can provide value add in primarily the
following areas:

* Provide a client side JavaScript library that does the grunt work
  of making the back-end XmlHttpRequest call, and updating the
  corresponding portion of your DOM.  Martin likes DOJO for this;
  there are also a bunch of other libraries that do the same sort
  of thing that should be leveraged, instead of inventing something new.

* Provide a server side framework that makes it easy to map
  a particular XHR invocation to the corresponding business logic,
  and (for extra credit) maps the response data to a generic data
  format so you don't have to write specific formatting logic for
  every single response type.  I sort of like what JSON provides as a
  transport protocol, but there's room for value add here on the
  server side, with a generic data abstraction that maps into
  the appropriate transport formats.

* Provide encapsulated functionality (JSP custom tags, JSF component
  tags, whatever) that totally hides the fact that Ajax techniques are used
  into the HTML and JavaScript markup that is automatically generated.
  If you make the page developer have to do a *lot* more (i.e. a bunch of
  nested tags) on every Ajax-sensitive component, that doesn't seem to
  make application development easier ... it only makes it more tedious.

Use case to consider -- as an application developer, I want to use a
progress bar "widget" that periodically polls the server for the
progress of a long running function, and then updates the client side
visual representation.  If I have to do more than add a single
attribute (some way to map to the server side function that returns
the completion percentage to be displayed), plus an optional parameter
that says how often to check, over what it takes to specify a static
image with an  tag (for example), then I'm likely to say
"thanks but no thanks" to your version of that widget.

If, on the other hand, you let me say:

  

or

  

then I'm fat, dumb, and happy.  Why should *i* (the application
developer) care that you're using XmlHttpRequest behind the scenes?

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: java.lang.IllegalArgumentException calling an Action

[brenmcguire]

Probably the problem is in your ActionForm. It seems that a submitted form
field does not match with the corresponding ActionForm property (e.g. you
submit a alphanumeric string while in the ActionForm the property is
"int").
Hope it helps.
Ciao
Antonio Petrelli

Rodolfo García Esteban/CYII wrote:

>Hi all,
>
>I'm developing with struts 1.2.4, I have an action with form as beans,
not
>dynamic, field in which I introduce data are String, and I have another
>field without values. When I do commit, then programs doesn't touch my
>action I obtain befere the next error:
>
>javax.servlet.ServletException: BeanUtils.populate
> org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497)
>
>org.apache.struts.action.RequestProcessor.processPopulate(RequestProcesso
r.java:798)
>
>org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:2
05)
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>
>Root Cause:
>
>java.lang.IllegalArgumentException: argument type mismatch
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>Method)
>
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
:39)
>
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
mpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:324)
>
>org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtil
s.java:1789)
>
>org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtil
s.java:1684)
>
>org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java
:1713)
> org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019)
> org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)
> org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495)
>
>org.apache.struts.action.RequestProcessor.processPopulate(RequestProcesso
r.java:798)
>
>org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:2
05)
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>
>
>Could somebody help me?
>
>Thanks
>
>
>Rodolfo ___
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using validate() and returning to original page dynamically

[Michael J.]

Hi Nic,

Struts does not allow to do things like this declaratively, but you
can do it manually.

1) you can obtain mapping name from the ActionMapping. This will
solidify the mapping name where you want to return, in code. I am not
sure that this is worse that to solidify it in struts-config.xml, but
people say that struts-config.xml is "more flexible in deploy time".
Hardly.

2) You can set the params too, it is not a big deal. Do not edit
existing ActionForward from findForward, instead create a new one and
append query parameters.

Referer is a great thing, but some browsers and firewalls can turn it
off, so it is not reliable.

On the other hand, are you sure that you want to design your actions
like this? How about this:

* createItem - creates new empty item; forwards (better yet,
redirects) to editItem.
* editItem - allows to set/change value for a new or for an existing item;
* storeItem - persists modified item (inserts the one just created or
updates already existing, called from editItem);

But in this case, if you use redirection, you would need to patch the
path to the action too, to include item ID. If interested, see more
here: http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost2.
It has a link to the source code, too.

WBR,
   Michael Jouravlev.

On 4/18/05, Nic Werner <[EMAIL PROTECTED]> wrote:
> Hi again,
> I'm calling the validate() method in my MappingDispatchAction to
> check errors on page. Which is fine, except that I want to return to the
> URL (Action w/params) that was called. I have two Actions, Edit and Add,
> which both refer to Attributes.jsp, and depending on the type param set,
> this page forwards to either Update or Insert, respectively. Therefore,
> setting 'input='Attributes.jsp' won't work as the bean isn't setup
> properly for the Edit Action.
> So, the flow is that I want '/Edit.do?Id=32' to check for errors,
> and if there is one, return to '/Edit.do?Id=32', not Attributes.jsp. It
> isn't enough to set the type (Edit/Add) in the session scope, I would
> need to set the params also, which seems like more complex
> handling/overhead.
> Is there a solution workaround to this? I've searched, and of course
> Rick has written some good articles on this, but I haven't seen the
> situation where it needs to return to a dynamic page *with* the params,
> aka the calling page.
> 
> I suppose I could get the referer URI, but I don't think I could
> call mapping.getInput() that way.
> 
> Thanks,
> 
> - Nic.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Martin Cooper]

To get beyond doing the grunt work yourself for Ajax, I recommend taking a
look at this:

http://dojotoolkit.org/intro_to_dojo_io.html

and downloading the dojo.io package from their site.

Personally, I'm not convinced that we need anything new in Struts to make
using Ajax easier. I'm building products today that make extensive use of
the two technologies together, and haven't found a need to enhance Struts to
do it. However, if we do add any Ajax (or Ajax-like) support to Struts, I
want to be able to plug in my plumbing of choice (which would be Dojo right
now) to get the most robust communication scheme available.

--
Martin Cooper


"Stéphane Zuckerman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Rodolfo García Esteban/CYII a écrit :
> > Where do we find information about this marvellous stuff?
> > 
> > Rodolfo __
>
> Look for "XMLHttpRequest" and/or ActiveXObject("Microsoft.XMLHTTP")
> XML.com and the Apple dev center have good introductory articles about it.
>
> Basically, this is a way to make server call from JavaScript via the
> XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer)
> objects. Thus it enables you to make dynamic calls to refresh some parts
> of a web page without reloading everything.
>
> This is used with gmail for instance.
>
> -- 
> Stéphane Zuckerman




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Using validate() and returning to original page dynamically

[Nic Werner]

Hi again,
   I'm calling the validate() method in my MappingDispatchAction to 
check errors on page. Which is fine, except that I want to return to the 
URL (Action w/params) that was called. I have two Actions, Edit and Add, 
which both refer to Attributes.jsp, and depending on the type param set, 
this page forwards to either Update or Insert, respectively. Therefore, 
setting 'input='Attributes.jsp' won't work as the bean isn't setup 
properly for the Edit Action.
   So, the flow is that I want '/Edit.do?Id=32' to check for errors, 
and if there is one, return to '/Edit.do?Id=32', not Attributes.jsp. It 
isn't enough to set the type (Edit/Add) in the session scope, I would 
need to set the params also, which seems like more complex 
handling/overhead.
   Is there a solution workaround to this? I've searched, and of course 
Rick has written some good articles on this, but I haven't seen the 
situation where it needs to return to a dynamic page *with* the params, 
aka the calling page.

   I suppose I could get the referer URI, but I don't think I could 
call mapping.getInput() that way.

Thanks,
- Nic.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Identify users

[Michael J.]

Struts and web browser already verified it for you. The whole point of
establishing a session is to correlate a browser to the server.
Browser already sends a cookie containing session ID to the server
along with each request. So as long as you can retrieve the user
object from the session, corresponding to incoming request, you know
that you are dealing with the right guy.

Search keyword: "session tracking".

On 4/18/05, Yan Hu <[EMAIL PROTECTED]> wrote:
> I need to check if a user is the one who has permission to a certain action.
> His role is stored in the database, for example  user.isStudent.  
> The whole student object is stored in the session after he logs in 
> successfully .
> From that point on, every time he sends a request that invokes an action ,
> I need to verify if this student is who he claims he is.  I could
> include a hidden field for example, his email in every page I send back
> to him and get this property back to verify who he is.  I was wondering
> if this approach is problematic since he could manipulate the hidden field.
> Any better solutions to that?Thanks a lot!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Identify users

[Fogleson, Allen]

But if the user is in the session, then we know that when he submits a
request, or at least when that browser submits a request it is the user
who is in the session. You could store roles for the user in the session
also and then just use the session.. if the role is not present populate
it from the DB and use the session thereafter.

Al


-Original Message-
From: Yan Hu [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 8:46 PM
To: Struts Users Mailing List; Daniel Watrous
Subject: Identify users

Hi:
I have a question.I need to check if a user is the one who has
permission to a certain action.
   His role is stored in the database, for example  user.isStudent.  The
whole student object is
stored in the session after he logs in successfully .  From that point
on, every time he sends a
request that invokes an action , I need to verify if this student is who
he claims he is.  I could
include a hidden field for example, his email in every page I send back
to him and get this
property back to verify who he is.  I was wondering if this approach is
problematic since he could
manipulate the hidden field.  Any better solutions to that?Thanks a
lot!




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Identify users

[Yan Hu]

Hi:
I have a question.I need to check if a user is the one who has permission 
to a certain action.
   His role is stored in the database, for example  user.isStudent.  The whole 
student object is
stored in the session after he logs in successfully .  From that point on, 
every time he sends a
request that invokes an action , I need to verify if this student is who he 
claims he is.  I could
include a hidden field for example, his email in every page I send back to him 
and get this
property back to verify who he is.  I was wondering if this approach is 
problematic since he could
manipulate the hidden field.  Any better solutions to that?Thanks a lot!




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: binary view

[Folashade Adeyosoye]

This might be a good case to write a custom tag.



-Original Message-
From: Daniel Watrous [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 5:20 PM
To: user@struts.apache.org
Subject: binary view

I have an action in my application that generates a PNG image from
some text stored in a session object.  My view is very simple:

<[EMAIL PROTECTED] contentType="image/png"%>
<%
java.io.OutputStream os = response.getOutputStream();
java.awt.image.BufferedImage buffer = (java.awt.image.BufferedImage)
request.getAttribute("imageBuffer");
javax.imageio.ImageIO.write(buffer,"png",os);
os.close();
%>

Thats it.  My action loads imageBuffer with the image data.

The first time I load the page I get the error:
"java.lang.IllegalStateException: getOutputStream() has already been
called for this response"

Is there a better way to accomplish what I am after?  I would prefer
to load the page one time and have it work, rather than the refresh. 
Thanks in advance...

DW

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: binary view

[Larry Meadors]

Why even bother with a jsp?

You have the response object in your action, just start spewing data into 
it.

Larry

On 4/18/05, Daniel Watrous <[EMAIL PROTECTED]> wrote:
> 
> I have an action in my application that generates a PNG image from
> some text stored in a session object. My view is very simple:
> 
> <[EMAIL PROTECTED] contentType="image/png"%>
> <%
> java.io.OutputStream os = response.getOutputStream();
> java.awt.image.BufferedImage buffer = (java.awt.image.BufferedImage)
> request.getAttribute("imageBuffer");
> javax.imageio.ImageIO.write(buffer,"png",os);
> os.close();
> %>
> 
> Thats it. My action loads imageBuffer with the image data.
> 
> The first time I load the page I get the error:
> "java.lang.IllegalStateException: getOutputStream() has already been
> called for this response"
> 
> Is there a better way to accomplish what I am after? I would prefer
> to load the page one time and have it work, rather than the refresh.
> Thanks in advance...
> 
> DW
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

RE: binary view

[Smith, Thad]

The problem is that you're opening the output stream at the beginning of
your jsp and then reopening the output stream by calling
response.getOutputStream(). I believe you can call response.reset() to
fix this problem:

<%
response.reset();
response.setContentType("image/png");
java.io.OutputStream os = response.getOutputStream();
java.awt.image.BufferedImage buffer = (java.awt.image.BufferedImage)
request.getAttribute("imageBuffer");
javax.imageio.ImageIO.write(buffer,"png",os);
os.flush();
os.close();
%>

Regards,

Thad Smith

-Original Message-
From: Daniel Watrous [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 4:20 PM
To: user@struts.apache.org
Subject: binary view

I have an action in my application that generates a PNG image from
some text stored in a session object.  My view is very simple:

<[EMAIL PROTECTED] contentType="image/png"%>
<%
java.io.OutputStream os = response.getOutputStream();
java.awt.image.BufferedImage buffer = (java.awt.image.BufferedImage)
request.getAttribute("imageBuffer");
javax.imageio.ImageIO.write(buffer,"png",os);
os.close();
%>

Thats it.  My action loads imageBuffer with the image data.

The first time I load the page I get the error:
"java.lang.IllegalStateException: getOutputStream() has already been
called for this response"

Is there a better way to accomplish what I am after?  I would prefer
to load the page one time and have it work, rather than the refresh. 
Thanks in advance...

DW

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

content management tool

[sudip shrestha]

Just curious if there are any struts based content managment tools out there!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

binary view

[Daniel Watrous]

I have an action in my application that generates a PNG image from
some text stored in a session object.  My view is very simple:

<[EMAIL PROTECTED] contentType="image/png"%>
<%
java.io.OutputStream os = response.getOutputStream();
java.awt.image.BufferedImage buffer = (java.awt.image.BufferedImage)
request.getAttribute("imageBuffer");
javax.imageio.ImageIO.write(buffer,"png",os);
os.close();
%>

Thats it.  My action loads imageBuffer with the image data.

The first time I load the page I get the error:
"java.lang.IllegalStateException: getOutputStream() has already been
called for this response"

Is there a better way to accomplish what I am after?  I would prefer
to load the page one time and have it work, rather than the refresh. 
Thanks in advance...

DW

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[Dave Newton]

David Johnson wrote:
which part to you need to see? I'm s thankful for any help :)
 

All of it? What Hubert is asking is whether or not you override the 
execute method of the DispatchAction subclass, as that could easily 
munge up the dispatching. That's certainly among my top questions as well.

Generally the relevent portions of the struts-config and Action (in your 
case, the base Action as well) are usually enough.

Better too much information than too little, especially if you have a 
site you can put it on rather than sending it all to the entire list.

Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[David Johnson]

which part to you need to see? I'm s thankful for any help :)

On 4/18/05, Dave Newton <[EMAIL PROTECTED]> wrote: 
> 
> Hubert Rabago wrote:
> 
> >Does it have an execute() method? If so, what does the execute method do?
> >
> >
> Yeah--what you gave isn't enough. In order to diagnose we must see the
> code, because on the surface everything appears to be fine.
> 
> Dave
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
-Dave
[EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[Dave Newton]

Hubert Rabago wrote:
Does it have an execute() method?  If so, what does the execute method do?
 

Yeah--what you gave isn't enough.  In order to diagnose we must see the 
code, because on the surface everything appears to be fine.

Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[Hubert Rabago]

Does it have an execute() method?  If so, what does the execute method do?

Hubert

On 4/18/05, David Johnson <[EMAIL PROTECTED]> wrote:
> the BaseAction has
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> 
> private Log log;
> 
> and a constructor that initialized the log object so I can perform
> logging in all my actions.
> 
> In addition it has a checkAuth() method that makes sure the user is
> logged in properly.
> 
> 
> On 4/18/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> > One part I missed was when you said your base action is extending
> > DispatchAction.  What is it that your base action is doing?  It could
> > be conflicting with the dispatch logic.
> >
> > Hubert
> >
> > On 4/18/05, [EMAIL PROTECTED]
> > <[EMAIL PROTECTED]> wrote:
> > > You've confirm that you've changed the action-mapping so that it is now
> > > using your new dispatch action?  If that's correct, then I'd say you need
> > > to break at DispatchAction.execute() and step through it to see what's
> > > going on.
> > >
> > > Dennis
> > >
> > >
> > > David Johnson <[EMAIL PROTECTED]>
> > > 04/18/2005 03:28 PM
> > > Please respond to
> > > "Struts Users Mailing List" 
> > >
> > > To
> > > Struts Users Mailing List , Hubert Rabago
> > > <[EMAIL PROTECTED]>
> > > cc
> > >
> > > Subject
> > > Re: Dispatch Action Strangeness
> > >
> > >
> > > yes, exactly. If changed the value of the hidden field to "graph"
> > >
> > > That part is working too. If I do a log.debug
> > > ("dispatch="+theForm.getDispatch());
> > >
> > > it puts out the right value (graph or whatever I clicked in the form)
> > >
> > > On 4/18/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> > > > IIRC you wanted the "graph" method to be called because you had
> > > > "set('graph')" in an onclick handler.  What does the "set('graph')"
> > > > method do?  Does it modify the "dispatch" form field?
> > > >
> > > > On 4/18/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > > > > Any further insights on this? It seems I'm missing something simple
> > > here...
> > > > >
> > > > > I dont want ot have to manually call methods on my action...
> > > > >
> > > > > help?  :)
> > > > >
> > > > > Is there something beyond the
> > > > >
> > > > > 
> > > > >
> > > > > that I need (and the hidden field named "dispatch")
> > > > >
> > > > > and of course to have my Action inherit from
> > > > > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > > > > inherits from it... that wouldnt make a diffference though correct?
> > > > >
> > > > > On 4/15/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > > > > > in my HTML I have
> > > > > >
> > > > > > 
> > > > > >
> > > > > > in my struts config (for the appropriate action) I have
> > > > > >
> > > > > > parameter="dispatch"
> > > > > >
> > > > > > Is there something else I need?
> > > > > >
> > > > > > On 4/15/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> > > > > > > David Johnson wrote the following on 4/15/2005 3:21 PM:
> > > > > > > > I saw that after I sent it. I have changed it to inherit from
> > > > > > > > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > > > > > > > inherits from DispatchAction) but the methods still arent being
> > > > > > > > called.
> > > > > > >
> > > > > > > You sure you have the parameter property in your action mapping in
> > > your
> > > > > > > struts config?
> > > > > > >
> > > > > > > "set('graph'); I'm assuming is setting a hidden parameter (your
> > > dispatch
> > > > > > > parameter)... whatever that parameter is, is the one you need also
> > > > > > > defined in your action mapping.
> > > > > > >
> > > > > > > --
> > > > > > > Rick
> > > > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > --
> > > -Dave
> > > [EMAIL PROTECTED]
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> --
> -Dave
> [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[David Johnson]

the BaseAction has 
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

private Log log;

and a constructor that initialized the log object so I can perform
logging in all my actions.


In addition it has a checkAuth() method that makes sure the user is
logged in properly.


On 4/18/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> One part I missed was when you said your base action is extending
> DispatchAction.  What is it that your base action is doing?  It could
> be conflicting with the dispatch logic.
> 
> Hubert
> 
> On 4/18/05, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > You've confirm that you've changed the action-mapping so that it is now
> > using your new dispatch action?  If that's correct, then I'd say you need
> > to break at DispatchAction.execute() and step through it to see what's
> > going on.
> >
> > Dennis
> >
> >
> > David Johnson <[EMAIL PROTECTED]>
> > 04/18/2005 03:28 PM
> > Please respond to
> > "Struts Users Mailing List" 
> >
> > To
> > Struts Users Mailing List , Hubert Rabago
> > <[EMAIL PROTECTED]>
> > cc
> >
> > Subject
> > Re: Dispatch Action Strangeness
> >
> >
> > yes, exactly. If changed the value of the hidden field to "graph"
> >
> > That part is working too. If I do a log.debug
> > ("dispatch="+theForm.getDispatch());
> >
> > it puts out the right value (graph or whatever I clicked in the form)
> >
> > On 4/18/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> > > IIRC you wanted the "graph" method to be called because you had
> > > "set('graph')" in an onclick handler.  What does the "set('graph')"
> > > method do?  Does it modify the "dispatch" form field?
> > >
> > > On 4/18/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > > > Any further insights on this? It seems I'm missing something simple
> > here...
> > > >
> > > > I dont want ot have to manually call methods on my action...
> > > >
> > > > help?  :)
> > > >
> > > > Is there something beyond the
> > > >
> > > > 
> > > >
> > > > that I need (and the hidden field named "dispatch")
> > > >
> > > > and of course to have my Action inherit from
> > > > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > > > inherits from it... that wouldnt make a diffference though correct?
> > > >
> > > > On 4/15/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > > > > in my HTML I have
> > > > >
> > > > > 
> > > > >
> > > > > in my struts config (for the appropriate action) I have
> > > > >
> > > > > parameter="dispatch"
> > > > >
> > > > > Is there something else I need?
> > > > >
> > > > > On 4/15/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> > > > > > David Johnson wrote the following on 4/15/2005 3:21 PM:
> > > > > > > I saw that after I sent it. I have changed it to inherit from
> > > > > > > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > > > > > > inherits from DispatchAction) but the methods still arent being
> > > > > > > called.
> > > > > >
> > > > > > You sure you have the parameter property in your action mapping in
> > your
> > > > > > struts config?
> > > > > >
> > > > > > "set('graph'); I'm assuming is setting a hidden parameter (your
> > dispatch
> > > > > > parameter)... whatever that parameter is, is the one you need also
> > > > > > defined in your action mapping.
> > > > > >
> > > > > > --
> > > > > > Rick
> > > > > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > --
> > -Dave
> > [EMAIL PROTECTED]
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
-Dave
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[David Johnson]

yeah. this is my Action mapping







On 4/18/05, Dave Newton <[EMAIL PROTECTED]> wrote:
> David Johnson wrote:
> 
> >yes, exactly. If changed the value of the hidden field to "graph"
> >
> >That part is working too. If I do a log.debug
> >("dispatch="+theForm.getDispatch());
> >
> >it puts out the right value (graph or whatever I clicked in the form)
> >
> >
> What does the code for your base action (that subclasses DispatchAction)
> look like? I've never had any issues with DispatchAction or its
> subclasses, so I'm a little confused as to why it wouldn't work.
> 
> You probably already posted all of it, but the relevent snippets from
> struts-config, the JSP, the base action, and the action might be handy
> again :)
> 
> Dave
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
-Dave
[EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[Dave Newton]

David Johnson wrote:
yes, exactly. If changed the value of the hidden field to "graph" 

That part is working too. If I do a log.debug
("dispatch="+theForm.getDispatch());
it puts out the right value (graph or whatever I clicked in the form)
 

What does the code for your base action (that subclasses DispatchAction) 
look like? I've never had any issues with DispatchAction or its 
subclasses, so I'm a little confused as to why it wouldn't work.

You probably already posted all of it, but the relevent snippets from 
struts-config, the JSP, the base action, and the action might be handy 
again :)

Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

I should probably post this on the Wiki, but...

AJAX is just a new buzzword for an old concept: updating only portions of
a web page instead of everything at once.

Speaking for myself, I was doing what would now be called AJAX at least
five years ago, and I'm talking about in a production app.  I didn't use
XML, nor did I use XMLHttpRequest at all.  I used a hidden frame, as
Michael mentions, and some scripting.  I can remember (and probably still
have!) a proof-of-concept, from around '99 I'd bet, of sending and
receving XML and playing with it, both using XMLHttpRequest and not using
it.

Michael is correct to point out the asynchronous nature of AJAX, because
that's what it's all about, whether your talking XML or not, whether you
use XMLHttpRequest or not.  In case there is any question in anyones'
mind, asychronous in this case simply means calls back to the server aside
from the usual form submissions.  Of course a form submission itself is
technically asynchronous, but it has a slightly different meaning when
discussing AJAX... instead of being asynchronous relative to some normal
passage of time, it is relative to the typical form submissions of a
webapp.

The key point though is the updating of only portions of a page, or
perhaps not even updating anything visible in some cases... maybe for
instance you want to every 10 seconds download a list of stock prices and
use them when the user tries to submit a trade.  Ironically, that's
probably a great example of when you SHOULD NOT use AJAX, but I'm trying
to illustrate that there is no requirement that anything visual happen.

There probably does need to be a more generic term though because AJAX is
specifically dealing with asynchronus calls utilizing Javascript and
XML... so what if I constuct a simple comma-separated list and use
VBScript instead (assuming IE)?  It's *technically* not AJAX any more, but
the underlying concept is identical.  What is it then, AVAC?? :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 3:38 pm, Dakota Jack said:
> I think you might be misunderstanding this point.  And, I would invite
> Frank, when he gets time to explain it to you.
>
> Jack
>
> On 4/18/05, Michael J. <[EMAIL PROTECTED]> wrote:
>> From wiki:
>> > No one should be under the impression that you have to deal in XML
>> > or that you have to use the XMLHttpRequest object at all, contrary
>> > to the meaning of the AJAX moniker.
>>
>> Not that I really care about the name, but for me you do not use Ajax
>> if you do not use async HTTP calls, either with XMLHttpRequest or with
>> hidden iframe.
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[Hubert Rabago]

One part I missed was when you said your base action is extending
DispatchAction.  What is it that your base action is doing?  It could
be conflicting with the dispatch logic.

Hubert

On 4/18/05, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> You've confirm that you've changed the action-mapping so that it is now
> using your new dispatch action?  If that's correct, then I'd say you need
> to break at DispatchAction.execute() and step through it to see what's
> going on.
> 
> Dennis
> 
> 
> David Johnson <[EMAIL PROTECTED]>
> 04/18/2005 03:28 PM
> Please respond to
> "Struts Users Mailing List" 
> 
> To
> Struts Users Mailing List , Hubert Rabago
> <[EMAIL PROTECTED]>
> cc
> 
> Subject
> Re: Dispatch Action Strangeness
> 
> 
> yes, exactly. If changed the value of the hidden field to "graph"
> 
> That part is working too. If I do a log.debug
> ("dispatch="+theForm.getDispatch());
> 
> it puts out the right value (graph or whatever I clicked in the form)
> 
> On 4/18/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> > IIRC you wanted the "graph" method to be called because you had
> > "set('graph')" in an onclick handler.  What does the "set('graph')"
> > method do?  Does it modify the "dispatch" form field?
> >
> > On 4/18/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > > Any further insights on this? It seems I'm missing something simple
> here...
> > >
> > > I dont want ot have to manually call methods on my action...
> > >
> > > help?  :)
> > >
> > > Is there something beyond the
> > >
> > > 
> > >
> > > that I need (and the hidden field named "dispatch")
> > >
> > > and of course to have my Action inherit from
> > > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > > inherits from it... that wouldnt make a diffference though correct?
> > >
> > > On 4/15/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > > > in my HTML I have
> > > >
> > > > 
> > > >
> > > > in my struts config (for the appropriate action) I have
> > > >
> > > > parameter="dispatch"
> > > >
> > > > Is there something else I need?
> > > >
> > > > On 4/15/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> > > > > David Johnson wrote the following on 4/15/2005 3:21 PM:
> > > > > > I saw that after I sent it. I have changed it to inherit from
> > > > > > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > > > > > inherits from DispatchAction) but the methods still arent being
> > > > > > called.
> > > > >
> > > > > You sure you have the parameter property in your action mapping in
> your
> > > > > struts config?
> > > > >
> > > > > "set('graph'); I'm assuming is setting a hidden parameter (your
> dispatch
> > > > > parameter)... whatever that parameter is, is the one you need also
> > > > > defined in your action mapping.
> > > > >
> > > > > --
> > > > > Rick
> > > > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> --
> -Dave
> [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

Ah, I see.  In any case this doesn't require new tags.

Part of this is I'm not just talking about validation.  In fact I think
that's about the most pedestrian use of AJAX around!  It's the cooler kind
of things you can get away with like table sorting, like the example in my
article.  Not that there aren't 100 ways to do that ;)

Your right, the usual JS event handlers fire, but what you do then can get
interesting... for instance, do you need to call a function to construct
an XML document and send that?  Or construct a query string?  Or maybe
just call a URL with no parameters?  And then what happens when the
request comes back?  There is obviously a JS function to handle it, but
what does it do?

My proposal and the accompanying example seeks to answer those questions
with the typical "whatever is in this XML config file" answer.  There is
no way in the world I can account for every possible scenario, but I was
trying to put together a generic enough solution so that I could provide
many, if not most, of the most common usages and allow them to be used
just by playing with the config file.  Validation was actually one thing I
was NOT specifically going to deal with.  Maybe I should though.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 3:37 pm, Jason King said:
> Frank W. Zammetti wrote:
>
>>You lost me Jason... what extra tags are you referring to?  My proposal
>>specifically didn't require any new tags, only additions to the existing
>>ones.
>>
>>
>>
> You previously said:
>
why not just modify the existing
>>>Struts tags to have some at least minimal AJAX functionality?  But what
>>>does that really mean? Simply put, instead of calling some Javascript
>>>function on the client in response to, say, the onClick event of a
>>> button,
>>>we instead call a server-side process, get a response back and update
>>> some
>>>part of the page.
>
> My thought is you'd call normal js events anyway.  The js events would
> call xmlhttprequest.
> That way we continue to use the same taglibs without any changes
> necessary.  My though is that an HTML  tag doesn't need to know
> whether its being validated by pure javascript or javascript +
> xmlhttprequest or 
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[DGraham]

You've confirm that you've changed the action-mapping so that it is now 
using your new dispatch action?  If that's correct, then I'd say you need 
to break at DispatchAction.execute() and step through it to see what's 
going on.

Dennis



David Johnson <[EMAIL PROTECTED]> 
04/18/2005 03:28 PM
Please respond to
"Struts Users Mailing List" 


To
Struts Users Mailing List , Hubert Rabago 
<[EMAIL PROTECTED]>
cc

Subject
Re: Dispatch Action Strangeness






yes, exactly. If changed the value of the hidden field to "graph" 

That part is working too. If I do a log.debug
("dispatch="+theForm.getDispatch());

it puts out the right value (graph or whatever I clicked in the form)

On 4/18/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> IIRC you wanted the "graph" method to be called because you had
> "set('graph')" in an onclick handler.  What does the "set('graph')"
> method do?  Does it modify the "dispatch" form field?
> 
> On 4/18/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > Any further insights on this? It seems I'm missing something simple 
here...
> >
> > I dont want ot have to manually call methods on my action...
> >
> > help?  :)
> >
> > Is there something beyond the
> >
> > 
> >
> > that I need (and the hidden field named "dispatch")
> >
> > and of course to have my Action inherit from
> > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > inherits from it... that wouldnt make a diffference though correct?
> >
> > On 4/15/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > > in my HTML I have
> > >
> > > 
> > >
> > > in my struts config (for the appropriate action) I have
> > >
> > > parameter="dispatch"
> > >
> > > Is there something else I need?
> > >
> > > On 4/15/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> > > > David Johnson wrote the following on 4/15/2005 3:21 PM:
> > > > > I saw that after I sent it. I have changed it to inherit from
> > > > > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > > > > inherits from DispatchAction) but the methods still arent being
> > > > > called.
> > > >
> > > > You sure you have the parameter property in your action mapping in 
your
> > > > struts config?
> > > >
> > > > "set('graph'); I'm assuming is setting a hidden parameter (your 
dispatch
> > > > parameter)... whatever that parameter is, is the one you need also
> > > > defined in your action mapping.
> > > >
> > > > --
> > > > Rick
> > > >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
-Dave
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

Oh, *that* part of it I agree has to be there or we're talking about
something completely different.  It was the usage of XML that isn't
required, that was my point in writing that.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 3:28 pm, Michael J. said:
>>From wiki:
>> No one should be under the impression that you have to deal in XML
>> or that you have to use the XMLHttpRequest object at all, contrary
>> to the meaning of the AJAX moniker.
>
> Not that I really care about the name, but for me you do not use Ajax
> if you do not use async HTTP calls, either with XMLHttpRequest or with
> hidden iframe.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Dakota Jack]

I think you might be misunderstanding this point.  And, I would invite
Frank, when he gets time to explain it to you.

Jack

On 4/18/05, Michael J. <[EMAIL PROTECTED]> wrote:
> From wiki:
> > No one should be under the impression that you have to deal in XML
> > or that you have to use the XMLHttpRequest object at all, contrary
> > to the meaning of the AJAX moniker.
> 
> Not that I really care about the name, but for me you do not use Ajax
> if you do not use async HTTP calls, either with XMLHttpRequest or with
> hidden iframe.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Jason King]

Frank W. Zammetti wrote:
You lost me Jason... what extra tags are you referring to?  My proposal
specifically didn't require any new tags, only additions to the existing
ones.
 

You previously said:
why not just modify the existing
Struts tags to have some at least minimal AJAX functionality?  But what
does that really mean? Simply put, instead of calling some Javascript
function on the client in response to, say, the onClick event of a
button,
we instead call a server-side process, get a response back and update
some
part of the page.
My thought is you'd call normal js events anyway.  The js events would call 
xmlhttprequest.
That way we continue to use the same taglibs without any changes necessary.  My though is 
that an HTML  tag doesn't need to know whether its being validated by pure 
javascript or javascript + xmlhttprequest or 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[David Johnson]

yes, exactly. If changed the value of the hidden field to "graph" 

That part is working too. If I do a log.debug
("dispatch="+theForm.getDispatch());

it puts out the right value (graph or whatever I clicked in the form)

On 4/18/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> IIRC you wanted the "graph" method to be called because you had
> "set('graph')" in an onclick handler.  What does the "set('graph')"
> method do?  Does it modify the "dispatch" form field?
> 
> On 4/18/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > Any further insights on this? It seems I'm missing something simple here...
> >
> > I dont want ot have to manually call methods on my action...
> >
> > help?  :)
> >
> > Is there something beyond the
> >
> > 
> >
> > that I need (and the hidden field named "dispatch")
> >
> > and of course to have my Action inherit from
> > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > inherits from it... that wouldnt make a diffference though correct?
> >
> > On 4/15/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > > in my HTML I have
> > >
> > > 
> > >
> > > in my struts config (for the appropriate action) I have
> > >
> > > parameter="dispatch"
> > >
> > > Is there something else I need?
> > >
> > > On 4/15/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> > > > David Johnson wrote the following on 4/15/2005 3:21 PM:
> > > > > I saw that after I sent it. I have changed it to inherit from
> > > > > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > > > > inherits from DispatchAction) but the methods still arent being
> > > > > called.
> > > >
> > > > You sure you have the parameter property in your action mapping in your
> > > > struts config?
> > > >
> > > > "set('graph'); I'm assuming is setting a hidden parameter (your dispatch
> > > > parameter)... whatever that parameter is, is the one you need also
> > > > defined in your action mapping.
> > > >
> > > > --
> > > > Rick
> > > >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
-Dave
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Michael J.]

>From wiki:
> No one should be under the impression that you have to deal in XML
> or that you have to use the XMLHttpRequest object at all, contrary
> to the meaning of the AJAX moniker.

Not that I really care about the name, but for me you do not use Ajax
if you do not use async HTTP calls, either with XMLHttpRequest or with
hidden iframe.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Dakota Jack]

There is no problem using the name.  That is the name the people at
Adaptive Path want used.  It is not the name for a product.  It is the
name for a technology and there is no problem with being sued.  You
can just AJAX all you want.  The name is clean, but not cleanser. 
///;-)

Jack

On 4/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Your right, and I suggest we stop using the AJAX name lest someone get
> sued...
> 
> Might I suggest WOINA?  (W)hat's (O)ld (I)s (N)ew (A)gain.
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> On Mon, April 18, 2005 2:29 pm, Michael J. said:
> > This is all great, and ajax definetely rules, but is it OK to use
> > other's pictures without giving credit to their author, who by the
> > way, came up with this name:
> >
> > http://www.adaptivepath.com/publications/essays/archives/000385.php
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Dakota Jack]

Thanks tor this note.  Attribution supplied.  You might have done that yourself.

On 4/18/05, Michael J. <[EMAIL PROTECTED]> wrote:
> This is all great, and ajax definetely rules, but is it OK to use
> other's pictures without giving credit to their author, who by the
> way, came up with this name:
> 
> http://www.adaptivepath.com/publications/essays/archives/000385.php
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

You lost me Jason... what extra tags are you referring to?  My proposal
specifically didn't require any new tags, only additions to the existing
ones.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 2:43 pm, Jason King said:
> Frank,
> What do we need extra tags for?  We already have hooks to call
> javascript functions, whether those functions run 100% client-side or
> interact through an xmlhttp object or even through a 1x1 pixel iframe
> should be totally unknown to the individual input elements.
> Frank W. Zammetti wrote:
>
>>You are correct Joe, I made no attempt whatsoever to solve that
>> situation.
>>
>>In short (relatively!), for anyone trying to get a grasp on it, my
>>proposal boils down to this:
>>
>>We have these Struts tags that everyone (except ironically me, most of
>> the
>>time!) uses.  These tags have various event handlers attached to them.
>>These event handlers are client-side Javascript functions that do
>> whatever
>>it is they do.  We also have this AJAX thingamajig, whereby a client
>> calls
>>on a server, gets a response, and, usually, updates just a part of a web
>>page.  Rather than develop a whole new taglib with AJAX at its center
>>(which isn't a bad idea as an aside), why not just modify the existing
>>Struts tags to have some at least minimal AJAX functionality?  But what
>>does that really mean? Simply put, instead of calling some Javascript
>>function on the client in response to, say, the onClick event of a
>> button,
>>we instead call a server-side process, get a response back and update
>> some
>>part of the page. The point here is that you continue to use the existing
>>tags that you know and, presumably!, love... your existing pages don't
>> get
>>broken, you don't have to rewrite anything, but you can now introduce
>> this
>>AJAX stuff as needed without having to write all the details yourself.
>>Further, what if what was provided included a number of "standard"
>>functions that would cover maybe 90% of the situations you might want to
>>use AJAX, like updating the innerHTML of a span?  What if you could send
>>and received XML, or not, at your discretion?  What if the extra cost of
>>all this was an updated JAR, a Struts plug-in, a single new XML
>>configuration file, and an ID added to any form tag you wanted to have
>>this AJAX capability?  That, in a nutshell, is my proposal.
>>
>>I was not seeking to recreate the world in an AJAX image, and I was not
>>trying to cover every possible scenario that could arise.  My goal was to
>>expand what exists and what people use, giving them some extra
>>functionality they didn't have before.  Those that needed more
>> flexibility
>>and power would likely know to look elsewhere, those that had minimal
>>requirements or otherwise didn't have the requisite expertise just yet
>>could stay play with AJAX.
>>
>>I wasn't trying to create a Lexus, just a Yugo :)
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

http://www.omnytex.com/ajaxtags.zip is everything I have.  It is, I'd say,
partially real... There are some things I didn't do (most importantly the
reading in of the configuration file), but it is a real, working thing
there, mostly.  It certainly needs to be completed, but ultimately in
simplest form it isn't all that far off.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 3:03 pm, Günther Wieser said:
> ...and some very simple questions, i hope i didn't pass the answers in all
> the mails about ajax:
>
> - where can i get it (especially the struts extension, or was it just a
> proposal)?
> - if it is under development, is there a chance to get a snapshot and to
> contribute to the development?
>
> kr,
> guenther
>
> -Original Message-
> From: Günther Wieser [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 18, 2005 8:55 PM
> To: 'Struts Users Mailing List'; 'Dakota Jack'
> Subject: RE: AJAX: Whoa, Nellie!
>
> hi,
>
> after all the mail about the philosophical aspects of AJAX (javascript
> yes/no, etc.) i want to contribute that THIS IS THE SOLUTION i've been
> looking for for one of my current projects.
>
> so, do i want to have that in struts?
>
> YES, I WANT!
>
> where can i sign?
>
> frank, if i would pray my next prayer would be for you, but be sure that
> my
> next beer is for you!
>
> kr,
> guenther
>
> -Original Message-
> From: Dakota Jack [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 18, 2005 3:02 PM
> To: Struts Users Mailing List
> Subject: AJAX: Whoa, Nellie!
>
> I have been taking another look at the AJAX stuff that Frank Zammetti has
> provided.  This stuff is revolutionary.  Someone ought to be taking a
> close
> look at integrating such solutions, so far as it makes sense, into Struts.
> This is not a passing fancy, in my estimation.
> This is a real solution to a persistent problem.  Further, this moves the
> solution to where the problem exists, on the client.  I, for one, am
> getting
> excited.  I am not saying to be precipitous, so the usual mundane warnings
> can be kept aside.  But, this is not the usual thing.
>  This is a fundamental shift in architecture that makes clear sense.
>
> Jack
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

Forget whatever I was thinking, I think Jason is on the right track! 
Ironically, I add custom attributes all the time in numerous situations,
but it frankly escaped me as a possible solution here.

All you really need beyond this is probably a new tag that renders a JS
function that you can pass an object reference and it will do the setting
of the style for you.  So, you get:







 



Which emits:





function styleSwitcher(obj, error) {
 if (error) {
  obj.style = obj.errorStyle;
 } else {
  obj.style = obj.normalStyle;
 }
}




 



... or similar such thing (I'm just dumping off the top of my head here).

The developer has simply to call styleSwitcher(form.element, true); in the
validation code to switch the style to the error style or
styleSwitcher(form.element, false); to switch it back to normal.

Thanks Jason, even if it doesn't go this way I can very much see this
being helpful in my own work.  Great call!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 2:41 pm, Jason King said:
>
>>
>>
>> Now, you raise a good point as to how the Javascript could capitalize
>> on the presence of the errorStyle attribute, which normally is only
>> interpreted on page load.  That is, if you did any client side
>> validation, you'd probably like to be able to switch the style of the
>> invalid field to whatever was specified in "errorStyle" even if there
>> was no error when the page loaded.  This is valuable outside of the
>> specifics of an Ajax situation and would also apply to any client-side
>> validation.  Unfortunately, I'm having trouble seeing a particularly
>> clean way to do it which wouldn't involve loading down the base tags
>> (because of single inheritance) and even then, I think you'd have a
>> pretty contentious time getting people to agree on what the base tags
>> should output.  I guess maybe you could have some Application scoped
>> "input tag decorator" which could be invoked by the tag if present
>> while still leaving things open for customization...
>>
>> Joe
>>
>>
> This one is simple.  HTML ignores attributes it doesn't understand.
> That means all your input boxes etc. could have an errorStyle attribute
> defined (and probably a normalStyle as well) and then when the js
> validation code runs it could look to see if such attributes are defined
> and then copy the value of errorStyle or normalStyle as appropriate to
> style when validating.  In other words your emitted HTML would look like
>  errorStyle="itsucks" normalStyle="basicstyle" value="King"
> onChange="some_js_function(this)">
> The element renders correctly,  validators that don't flip styles ignore
> the extra attributes validators that use them have them.  I know its
> bizarre, adding atttributes to objects at run-time, but that's the world
> of the DOM.
> Its' been a while since I tested this, I believe if I have a text input
> object in the variable oTxt to find out its "errorStyle" attribute I
> have to use js like:
> var es = oTxt.getAttribute("errorStyle");  // returns null if no such
> attribute exists.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Günther Wieser]

...and some very simple questions, i hope i didn't pass the answers in all
the mails about ajax:

- where can i get it (especially the struts extension, or was it just a
proposal)?
- if it is under development, is there a chance to get a snapshot and to
contribute to the development?

kr,
guenther

-Original Message-
From: Günther Wieser [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 8:55 PM
To: 'Struts Users Mailing List'; 'Dakota Jack'
Subject: RE: AJAX: Whoa, Nellie!

hi, 

after all the mail about the philosophical aspects of AJAX (javascript
yes/no, etc.) i want to contribute that THIS IS THE SOLUTION i've been
looking for for one of my current projects.

so, do i want to have that in struts?

YES, I WANT!

where can i sign?

frank, if i would pray my next prayer would be for you, but be sure that my
next beer is for you!

kr,
guenther

-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED]
Sent: Monday, April 18, 2005 3:02 PM
To: Struts Users Mailing List
Subject: AJAX: Whoa, Nellie!

I have been taking another look at the AJAX stuff that Frank Zammetti has
provided.  This stuff is revolutionary.  Someone ought to be taking a close
look at integrating such solutions, so far as it makes sense, into Struts.
This is not a passing fancy, in my estimation. 
This is a real solution to a persistent problem.  Further, this moves the
solution to where the problem exists, on the client.  I, for one, am getting
excited.  I am not saying to be precipitous, so the usual mundane warnings
can be kept aside.  But, this is not the usual thing.
 This is a fundamental shift in architecture that makes clear sense.

Jack


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Dakota Jack]

Yes.  I agree with this wholeheartedly.  I wish we would do something
similar with the application specific code that is now in Struts. 
Plugins would not be the solution, but something akin to that.

On 4/18/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> No problemo.  As far as the extension itself is concerned, I'd still
> be interested in it, but like I mentioned earlier, only as a plugin
> that doesn't change the base tags.  The reasons are many and they are
> mentioned in the dev thread you started.  My main concern is
> implementation lock-in.  Another message in this thread already
> illustrates that there could be several approaches to adding this
> functionality.  I wouldn't want to limit how everyone else applies the
> technology.  As Martin said, if an implementation is built into
> Struts, it should support whatever client-side library the developer
> would want to use (
> http://marc.theaimsgroup.com/?l=struts-dev&m=111284722931074&w=2 ).  A
> separate plugin wouldn't have to have that burden.
> 
> A separated plugin would result in code duplication, true, but in my
> view it's worth it.  In some aspects, the ajax-aware tags you propose
> are in a better position than the EL tags.  You only need to override
> some methods, whose implementation can be moved to a util-type class.
> EL had to add duplicate fields, getters, and setters.  Just take a
> look at the source of some of those tags, like ELCheckboxTag and
> ELRadioTag.
> 
> Hubert
> 
> On 4/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> > Yep, sorry about that... I had it in my drafts folder because I got called
> > away in the middle of it, and I didn't check all the replies to the
> > current thread before sending it so I didn't see your link until
> > afterwards.  My bad :)
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> >
> > On Mon, April 18, 2005 10:41 am, Hubert Rabago said:
> > > Frank,
> > >
> > > You must've started typing this response a while ago.  I already sent
> > > a message on this thread linking to the dev email with your proposal.
> > >
> > > Hubert
> > >
> > > On 4/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> > >> On 4/6 I posted the following message to the Struts dev list... I can't
> > >> seem to find the thread in the list archives, if anyone else can I would
> > >> appreciate very much you posting the link to it...
> > >>
> > >> This was discussing my proposal for integrating AJAX functionality into
> > >> the existing Struts taglibs.  There were some legitimate dissenting
> > >> points
> > >> raised about this, and ultimately the idea was shot down.  However, I
> > >> still feel the idea has significant merit.
> > >>
> > >> The proposal wasn't posted to the user list, and maybe I should have
> > >> done
> > >> so... if there is support for this in the user community, I would be
> > >> willing to persue it further and provide it as part of the SF Struts
> > >> project.
> > >>
> > >> P.S., I've added some notes here for some things that may not be as
> > >> clear
> > >> as I would have liked, especially if you aren't terribly familiar with
> > >> the
> > >> Struts code base, so if you see minor difference between this and what
> > >> is
> > >> in the archives, that's all it is...
> > >>
> > >> 
> > >>
> > >> Subject: RFC: Struts HTML Ajax-Aware Tags
> > >>
> > >> Afternoon all,
> > >>
> > >> Please reference the code at:
> > >>
> > >> http://www.omnytex.com/ajaxtags.zip
> > >>
> > >> This is a complete webapp demonstrating the proposal (it isn't complete,
> > >> it is just to get the ideas across).
> > >>
> > >> I wanted to put something out there in front of you all and get some
> > >> feedback on it before I go that extra mile and finish it out.
> > >>
> > >> This came out of some ideas I tossed at Ted a few days ago.  The basic
> > >> idea is to take the existing Struts HTML taglib and make the tags
> > >> Ajax-aware.
> > >>
> > >> In a nuthsell, take a simple button tag...
> > >>
> > >> 
> > >>
> > >> ...now, add a new attribute to it, ajaxRef:
> > >>
> > >>  > >> ajaxRef="button1" />
> > >>
> > >> When the tag is rendered, each possible type of event handler (in the
> > >> BaseTagHandler class) looks something like this now:
> > >>
> > >> if (getOnclick() != null) {
> > >> handlers.append(" onclick=\"");
> > >> handlers.append(getOnclick());
> > >> handlers.append("\"");
> > >> }
> > >> else {
> > >>   prepareAjax("onclick", handlers);
> > >> }
> > >>
> > >> prepareAjax() does a lookup to a new XML configuration file (well,
> > >> in-memory objects representing the XML of course!) like so:
> > >>
> > >> 
> > >>   
> > >> button1
> > >> 
> > >>   onClick
> > >>   queryString
> > >>   buttonValue=button1,textValue=text1
> > >>   http://www.omnytex.com
> > >>   stdInnerHTML
> > >>   resultLayer
> > >> 
> > >>   
> > >> 
> > >>
> > >> If an  with an  m

RE: AJAX: Whoa, Nellie!

[Günther Wieser]

hi, 

after all the mail about the philosophical aspects of AJAX (javascript
yes/no, etc.) i want to contribute that THIS IS THE SOLUTION i've been
looking for for one of my current projects.

so, do i want to have that in struts?

YES, I WANT!

where can i sign?

frank, if i would pray my next prayer would be for you, but be sure that my
next beer is for you!

kr,
guenther

-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 3:02 PM
To: Struts Users Mailing List
Subject: AJAX: Whoa, Nellie!

I have been taking another look at the AJAX stuff that Frank Zammetti has
provided.  This stuff is revolutionary.  Someone ought to be taking a close
look at integrating such solutions, so far as it makes sense, into Struts.
This is not a passing fancy, in my estimation. 
This is a real solution to a persistent problem.  Further, this moves the
solution to where the problem exists, on the client.  I, for one, am getting
excited.  I am not saying to be precipitous, so the usual mundane warnings
can be kept aside.  But, this is not the usual thing.
 This is a fundamental shift in architecture that makes clear sense.

Jack


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Jason King]

Frank,
What do we need extra tags for?  We already have hooks to call 
javascript functions, whether those functions run 100% client-side or 
interact through an xmlhttp object or even through a 1x1 pixel iframe 
should be totally unknown to the individual input elements.
Frank W. Zammetti wrote:

You are correct Joe, I made no attempt whatsoever to solve that situation.
In short (relatively!), for anyone trying to get a grasp on it, my
proposal boils down to this:
We have these Struts tags that everyone (except ironically me, most of the
time!) uses.  These tags have various event handlers attached to them. 
These event handlers are client-side Javascript functions that do whatever
it is they do.  We also have this AJAX thingamajig, whereby a client calls
on a server, gets a response, and, usually, updates just a part of a web
page.  Rather than develop a whole new taglib with AJAX at its center
(which isn't a bad idea as an aside), why not just modify the existing
Struts tags to have some at least minimal AJAX functionality?  But what
does that really mean? Simply put, instead of calling some Javascript
function on the client in response to, say, the onClick event of a button,
we instead call a server-side process, get a response back and update some
part of the page. The point here is that you continue to use the existing
tags that you know and, presumably!, love... your existing pages don't get
broken, you don't have to rewrite anything, but you can now introduce this
AJAX stuff as needed without having to write all the details yourself. 
Further, what if what was provided included a number of "standard"
functions that would cover maybe 90% of the situations you might want to
use AJAX, like updating the innerHTML of a span?  What if you could send
and received XML, or not, at your discretion?  What if the extra cost of
all this was an updated JAR, a Struts plug-in, a single new XML
configuration file, and an ID added to any form tag you wanted to have
this AJAX capability?  That, in a nutshell, is my proposal.

I was not seeking to recreate the world in an AJAX image, and I was not
trying to cover every possible scenario that could arise.  My goal was to
expand what exists and what people use, giving them some extra
functionality they didn't have before.  Those that needed more flexibility
and power would likely know to look elsewhere, those that had minimal
requirements or otherwise didn't have the requisite expertise just yet
could stay play with AJAX.
I wasn't trying to create a Lexus, just a Yugo :)
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[Hubert Rabago]

IIRC you wanted the "graph" method to be called because you had
"set('graph')" in an onclick handler.  What does the "set('graph')"
method do?  Does it modify the "dispatch" form field?

On 4/18/05, David Johnson <[EMAIL PROTECTED]> wrote:
> Any further insights on this? It seems I'm missing something simple here...
> 
> I dont want ot have to manually call methods on my action...
> 
> help?  :)
> 
> Is there something beyond the
> 
> 
> 
> that I need (and the hidden field named "dispatch")
> 
> and of course to have my Action inherit from
> org.apache.struts.actions.DispatchAction (actually my BaseAction
> inherits from it... that wouldnt make a diffference though correct?
> 
> On 4/15/05, David Johnson <[EMAIL PROTECTED]> wrote:
> > in my HTML I have
> >
> > 
> >
> > in my struts config (for the appropriate action) I have
> >
> > parameter="dispatch"
> >
> > Is there something else I need?
> >
> > On 4/15/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> > > David Johnson wrote the following on 4/15/2005 3:21 PM:
> > > > I saw that after I sent it. I have changed it to inherit from
> > > > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > > > inherits from DispatchAction) but the methods still arent being
> > > > called.
> > >
> > > You sure you have the parameter property in your action mapping in your
> > > struts config?
> > >
> > > "set('graph'); I'm assuming is setting a hidden parameter (your dispatch
> > > parameter)... whatever that parameter is, is the one you need also
> > > defined in your action mapping.
> > >
> > > --
> > > Rick
> > >

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Jason King]

Now, you raise a good point as to how the Javascript could capitalize 
on the presence of the errorStyle attribute, which normally is only 
interpreted on page load.  That is, if you did any client side 
validation, you'd probably like to be able to switch the style of the 
invalid field to whatever was specified in "errorStyle" even if there 
was no error when the page loaded.  This is valuable outside of the 
specifics of an Ajax situation and would also apply to any client-side 
validation.  Unfortunately, I'm having trouble seeing a particularly 
clean way to do it which wouldn't involve loading down the base tags 
(because of single inheritance) and even then, I think you'd have a 
pretty contentious time getting people to agree on what the base tags 
should output.  I guess maybe you could have some Application scoped 
"input tag decorator" which could be invoked by the tag if present 
while still leaving things open for customization...

Joe

This one is simple.  HTML ignores attributes it doesn't understand.  
That means all your input boxes etc. could have an errorStyle attribute 
defined (and probably a normalStyle as well) and then when the js 
validation code runs it could look to see if such attributes are defined 
and then copy the value of errorStyle or normalStyle as appropriate to 
style when validating.  In other words your emitted HTML would look like

The element renders correctly,  validators that don't flip styles ignore 
the extra attributes validators that use them have them.  I know its 
bizarre, adding atttributes to objects at run-time, but that's the world 
of the DOM. 
Its' been a while since I tested this, I believe if I have a text input 
object in the variable oTxt to find out its "errorStyle" attribute I 
have to use js like:
var es = oTxt.getAttribute("errorStyle");  // returns null if no such 
attribute exists.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[DGraham]

What?






"Michael J." <[EMAIL PROTECTED]> 
04/18/2005 02:29 PM
Please respond to
"Struts Users Mailing List" 


To
Struts Users Mailing List 
cc

Subject
Re: AJAX: Whoa, Nellie!






This is all great, and ajax definetely rules, but is it OK to use
other's pictures without giving credit to their author, who by the
way, came up with this name:

http://www.adaptivepath.com/publications/essays/archives/000385.php

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

Your right, and I suggest we stop using the AJAX name lest someone get
sued...

Might I suggest WOINA?  (W)hat's (O)ld (I)s (N)ew (A)gain.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 2:29 pm, Michael J. said:
> This is all great, and ajax definetely rules, but is it OK to use
> other's pictures without giving credit to their author, who by the
> way, came up with this name:
>
> http://www.adaptivepath.com/publications/essays/archives/000385.php
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Michael J.]

This is all great, and ajax definetely rules, but is it OK to use
other's pictures without giving credit to their author, who by the
way, came up with this name:

http://www.adaptivepath.com/publications/essays/archives/000385.php

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

On Mon, April 18, 2005 2:13 pm, Joe Germuska said:
>>I am not quite sure why "the overhead makes it impractical," unless there
>> is
>>a physical barrier such as bandwidth restraint -- but that sounds like a
>>case-by-case decision is required.
>
> Well, by definition, an XMLHttpRequest involves a request/response.
> I suppose it's true that a blanket statement against is in
> appropriate, considering that things like Google Maps do lots of XML
> R/R every time you drag the map around.

And the one thing that people tend to forget when thinking about AJAX is
that there is nothing that says you have to use XML at all (well, aside
from the ACRONYM of course!).  It works just as well if you do nothing but
query string to the server and simple CSV values back (depending on what
your doing naturally).  In fact, I don't think any of the examples in my
article used XML, at least not submitted to the server.

The point is that while you are dead-on Joe, much of that overhead can be
alleviated by not using XML at all, seemingly in defiance of the technique
in use :)

> It seems like validating a date is particularly a case where
> JavaScript should be able to do it fine without a network call --
> unless you want to have some kind of scheduler app which checks to
> see if a date is "available" or something.

No doubt.  There are some things that I think people are just plain NUTS
for not doing client-side.  The format of a date entry is a good example.

> Now, you raise a good point as to how the Javascript could capitalize
> on the presence of the errorStyle attribute, which normally is only
> interpreted on page load.  That is, if you did any client side
> validation, you'd probably like to be able to switch the style of the
> invalid field to whatever was specified in "errorStyle" even if there
> was no error when the page loaded.  This is valuable outside of the
> specifics of an Ajax situation and would also apply to any
> client-side validation.  Unfortunately, I'm having trouble seeing a
> particularly clean way to do it which wouldn't involve loading down
> the base tags (because of single inheritance) and even then, I think
> you'd have a pretty contentious time getting people to agree on what
> the base tags should output.  I guess maybe you could have some
> Application scoped "input tag decorator" which could be invoked by
> the tag if present while still leaving things open for
> customization...

I actually have some ideas about this Joe, but they aren't completely
formed in my brain yet... I'm also not sure any of them will be any good
once they are, but if I belive they are I'll post them.  What I'm thinking
about is the kind of stuff I've done in some of my apps which sound oh so
close to what your talking about here... if I can generalize the code I
use to do it, then it could wind up being useful to solve this problem.

Frank

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Joe Germuska]

At 1:59 PM -0400 4/18/05, Benedict, Paul C wrote:
Joe writes:
Otherwise, Paul, I'm not sure what you mean...  is your idea that an
XMLHttpRequest call would be made to do server-side validation for
each form update?  The overhead is likely to make that an impractical
solution.  Or are you wondering how errors would be reported back to
the page as a response from an XMLHttpRequest?
I am not quite sure why "the overhead makes it impractical," unless there is
a physical barrier such as bandwidth restraint -- but that sounds like a
case-by-case decision is required.
Well, by definition, an XMLHttpRequest involves a request/response. 
I suppose it's true that a blanket statement against is in 
appropriate, considering that things like Google Maps do lots of XML 
R/R every time you drag the map around.

But I've seen some forms, which I think AJAX runs behind the scenes to do
validation. (If I can re-find a link I will send it.) When a non-date field
is entered into a date field, for instance, an error message is shown to its
side. This client-side reporting is akin to the errorStyles, which were
added to the Struts 1.2.5 tags to allow per-field reporting on the
server-side.
It seems like validating a date is particularly a case where 
JavaScript should be able to do it fine without a network call -- 
unless you want to have some kind of scheduler app which checks to 
see if a date is "available" or something.

Now, you raise a good point as to how the Javascript could capitalize 
on the presence of the errorStyle attribute, which normally is only 
interpreted on page load.  That is, if you did any client side 
validation, you'd probably like to be able to switch the style of the 
invalid field to whatever was specified in "errorStyle" even if there 
was no error when the page loaded.  This is valuable outside of the 
specifics of an Ajax situation and would also apply to any 
client-side validation.  Unfortunately, I'm having trouble seeing a 
particularly clean way to do it which wouldn't involve loading down 
the base tags (because of single inheritance) and even then, I think 
you'd have a pretty contentious time getting people to agree on what 
the base tags should output.  I guess maybe you could have some 
Application scoped "input tag decorator" which could be invoked by 
the tag if present while still leaving things open for 
customization...

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

You are correct Joe, I made no attempt whatsoever to solve that situation.

In short (relatively!), for anyone trying to get a grasp on it, my
proposal boils down to this:

We have these Struts tags that everyone (except ironically me, most of the
time!) uses.  These tags have various event handlers attached to them. 
These event handlers are client-side Javascript functions that do whatever
it is they do.  We also have this AJAX thingamajig, whereby a client calls
on a server, gets a response, and, usually, updates just a part of a web
page.  Rather than develop a whole new taglib with AJAX at its center
(which isn't a bad idea as an aside), why not just modify the existing
Struts tags to have some at least minimal AJAX functionality?  But what
does that really mean? Simply put, instead of calling some Javascript
function on the client in response to, say, the onClick event of a button,
we instead call a server-side process, get a response back and update some
part of the page. The point here is that you continue to use the existing
tags that you know and, presumably!, love... your existing pages don't get
broken, you don't have to rewrite anything, but you can now introduce this
AJAX stuff as needed without having to write all the details yourself. 
Further, what if what was provided included a number of "standard"
functions that would cover maybe 90% of the situations you might want to
use AJAX, like updating the innerHTML of a span?  What if you could send
and received XML, or not, at your discretion?  What if the extra cost of
all this was an updated JAR, a Struts plug-in, a single new XML
configuration file, and an ID added to any form tag you wanted to have
this AJAX capability?  That, in a nutshell, is my proposal.

I was not seeking to recreate the world in an AJAX image, and I was not
trying to cover every possible scenario that could arise.  My goal was to
expand what exists and what people use, giving them some extra
functionality they didn't have before.  Those that needed more flexibility
and power would likely know to look elsewhere, those that had minimal
requirements or otherwise didn't have the requisite expertise just yet
could stay play with AJAX.

I wasn't trying to create a Lexus, just a Yugo :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 1:38 pm, Joe Germuska said:
> At 11:15 AM -0400 4/18/05, Benedict, Paul C wrote:
>>Frank, will Ajax support be tied into reporting form errors? It would be
>>interesting to break down the validator into individual validations, so
>>errors can be reported to the user as he types.
>
> Independent of Ajax, Niall Pemberton has done a substantial overhaul
> of commons-validator which will support per-field validation instead
> of only onsubmit.
>
> http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html
>
> It's really quite impressive, and I think it's only pending Niall
> having enough time to really give it a good run-through, since it's a
> pretty big change.
>
> Otherwise, Paul, I'm not sure what you mean...  is your idea that an
> XMLHttpRequest call would be made to do server-side validation for
> each form update?  The overhead is likely to make that an impractical
> solution.  Or are you wondering how errors would be reported back to
> the page as a response from an XMLHttpRequest?
>
> I don't think this is part of Frank's kit (sorry if it is and I
> missed it) but it makes sense from a framework standpoint to have
> standard XML representations of Struts concepts (like ActionMessages)
> paired with a JavaScript library that can convert those into a
> standardized JavaScript object model.  I haven't tried yet to solve
> any problems with Ajax where this would be useful, but it's
> definitely the kind of thing you wouldn't want to leave each person
> to have to rewrite him- or herself.
>
> Joe
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Benedict, Paul C]

Joe writes:
>>Otherwise, Paul, I'm not sure what you mean...  is your idea that an 
XMLHttpRequest call would be made to do server-side validation for 
each form update?  The overhead is likely to make that an impractical 
solution.  Or are you wondering how errors would be reported back to 
the page as a response from an XMLHttpRequest?

I am not quite sure why "the overhead makes it impractical," unless there is
a physical barrier such as bandwidth restraint -- but that sounds like a
case-by-case decision is required.

But I've seen some forms, which I think AJAX runs behind the scenes to do
validation. (If I can re-find a link I will send it.) When a non-date field
is entered into a date field, for instance, an error message is shown to its
side. This client-side reporting is akin to the errorStyles, which were
added to the Struts 1.2.5 tags to allow per-field reporting on the
server-side.

-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 1:38 PM
To: 'Struts Users Mailing List'
Subject: RE: AJAX: Whoa, Nellie!


At 11:15 AM -0400 4/18/05, Benedict, Paul C wrote:
>Frank, will Ajax support be tied into reporting form errors? It would be
>interesting to break down the validator into individual validations, so
>errors can be reported to the user as he types.

Independent of Ajax, Niall Pemberton has done a substantial overhaul 
of commons-validator which will support per-field validation instead 
of only onsubmit.

http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html

It's really quite impressive, and I think it's only pending Niall 
having enough time to really give it a good run-through, since it's a 
pretty big change.

Otherwise, Paul, I'm not sure what you mean...  is your idea that an 
XMLHttpRequest call would be made to do server-side validation for 
each form update?  The overhead is likely to make that an impractical 
solution.  Or are you wondering how errors would be reported back to 
the page as a response from an XMLHttpRequest?

I don't think this is part of Frank's kit (sorry if it is and I 
missed it) but it makes sense from a framework standpoint to have 
standard XML representations of Struts concepts (like ActionMessages) 
paired with a JavaScript library that can convert those into a 
standardized JavaScript object model.  I haven't tried yet to solve 
any problems with Ajax where this would be useful, but it's 
definitely the kind of thing you wouldn't want to leave each person 
to have to rewrite him- or herself.

Joe

-- 
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






--
Notice:  This e-mail message, together with any attachments, contains 
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New 
Jersey, USA 08889), and/or its affiliates (which may be known outside the 
United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as 
Banyu) that may be confidential, proprietary copyrighted and/or legally 
privileged. It is intended solely for the use of the individual or entity named 
on this message.  If you are not the intended recipient, and have received this 
message in error, please notify us immediately by reply e-mail and then delete 
it from your system.
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Benedict, Paul C]

Frank,

Thanks for your respectful rebuttal. My statement was pretty general and a
wide-range of exceptions exist for it, but I think we actually agree at the
end of the day when the whole picture painted. You're right to draw the
distinction between a SITE and APPLICATION, and sometimes JavaScript is a
mandatory requirement for applications. 

-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 1:41 PM
To: Struts Users Mailing List
Cc: 'Struts Users Mailing List'
Subject: RE: AJAX: Whoa, Nellie!


> But, it's a
> moot point, because, as I see it, no one's website should depend on
> JavaScript for it to be fully functional anymore than it should wholly
> rely
> on CSS.

I would have to respectfully disagree Paul.  While I think it's right to
say that not EVERYONE'S web site should require these things, it is
equally right to say that some should.

The point of divergance I think is the differentiation between web SITE
and web APPLICATION.  The former I would certainly agree should strive to
avoid requiring those things, but the later in many instances almost
requires requiring them :)

Those has been for a long time two schools of thought on web
development... one believes in what I call the "classical" model... they
feel that as little as possible should be done on the client.  They are
generally against (or shy away from) scripting and DHTML solutions.  They
can quote numerous reasons, most very valid, for their point of view:
security, ease of development and debugging, centralized code, etc.  One
of the characteristics of the things developed by this camp is that they
tend to not be especially user-friendly and usually at the opposite end of
the spectrum from the old fat-clients.  There are of course exceptions,
and everyone can name them, but as a generality that is true.

The other school of thought feels that you have immensely powerful client
machines accessing your site, so why not use them?  They believe that web
applications don't have to look like pages of static text with boring HTML
forms all over the place.  There are equally valid reasons for their point
of view: performance, richer user experiences and lower server utilization
(and thereby costs), etc.  They generally develop things that look, feel
and work more like fat-clients, however, they tend to be more complex,
requiring a higher degree of expertise to develop and maintain.

Both sides have valid points.  I personally fall in the later group, but I
swing to the other side sometimes (man, taken out of context my wife is
gonna KILL me!).

In any case, when you are talking about a web SITE, I think there is more
to be said for the classical camp, and just the opposite is true when
talking about a web APPLICATION.  What determines which something is? 
There are no hard and fast rules, but generally, if you are developing
something that you can't control or even know who will be accessing it,
you are developing a web SITE and you should think a different way than
someone developing something that will be accessed by a known audience. 
Note that having a known audience does NOT imply it is an internal
application, although that is true much of the time.  You can have an web
application that is outward-facing... a bank's web site is usually given
as an example of this (although some argue they wouldn't use a bank that
required then to use Javascript)... depending on what functionality that
banks' site provides, requiring Javascript might be justifiable.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 1:19 pm, Benedict, Paul C said:
> To Frank's point,
>
> I am sometimes one of those users who turn off JavaScript ;-) But, it's a
> moot point, because, as I see it, no one's website should depend on
> JavaScript for it to be fully functional anymore than it should wholly
> rely
> on CSS. These are technologies that enable powerful usability, but
> websites
> should gracefully degrade when they are not available.
>
> So Ajax should add "nice to have's", but not "must have's".
>
> -Original Message-
> From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 18, 2005 1:14 PM
> To: Struts Users Mailing List
> Cc: Struts Users Mailing List
> Subject: RE: AJAX: Whoa, Nellie!
>
>
> Users that turn off JS are akin, in my mind, to automobile drivers who
> decide they would rather play Fred Flintstone, cut holes in the
> floorboards and not bother starting the engine.  Oh, you'll get around,
> but your missing out!
>
> While I am certainly not trying to say there aren't very legitimate
> concerns with using JS, like most things they are overcome with knowledge
> and ability.  I mean, no one complains because Windows ships with fdisk
> and format, they are at least as dangerous potentially!
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex

RE: AJAX: Whoa, Nellie!

[Joe Germuska]

At 11:15 AM -0400 4/18/05, Benedict, Paul C wrote:
Frank, will Ajax support be tied into reporting form errors? It would be
interesting to break down the validator into individual validations, so
errors can be reported to the user as he types.
Independent of Ajax, Niall Pemberton has done a substantial overhaul 
of commons-validator which will support per-field validation instead 
of only onsubmit.

http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html
It's really quite impressive, and I think it's only pending Niall 
having enough time to really give it a good run-through, since it's a 
pretty big change.

Otherwise, Paul, I'm not sure what you mean...  is your idea that an 
XMLHttpRequest call would be made to do server-side validation for 
each form update?  The overhead is likely to make that an impractical 
solution.  Or are you wondering how errors would be reported back to 
the page as a response from an XMLHttpRequest?

I don't think this is part of Frank's kit (sorry if it is and I 
missed it) but it makes sense from a framework standpoint to have 
standard XML representations of Struts concepts (like ActionMessages) 
paired with a JavaScript library that can convert those into a 
standardized JavaScript object model.  I haven't tried yet to solve 
any problems with Ajax where this would be useful, but it's 
definitely the kind of thing you wouldn't want to leave each person 
to have to rewrite him- or herself.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

> But, it's a
> moot point, because, as I see it, no one's website should depend on
> JavaScript for it to be fully functional anymore than it should wholly
> rely
> on CSS.

I would have to respectfully disagree Paul.  While I think it's right to
say that not EVERYONE'S web site should require these things, it is
equally right to say that some should.

The point of divergance I think is the differentiation between web SITE
and web APPLICATION.  The former I would certainly agree should strive to
avoid requiring those things, but the later in many instances almost
requires requiring them :)

Those has been for a long time two schools of thought on web
development... one believes in what I call the "classical" model... they
feel that as little as possible should be done on the client.  They are
generally against (or shy away from) scripting and DHTML solutions.  They
can quote numerous reasons, most very valid, for their point of view:
security, ease of development and debugging, centralized code, etc.  One
of the characteristics of the things developed by this camp is that they
tend to not be especially user-friendly and usually at the opposite end of
the spectrum from the old fat-clients.  There are of course exceptions,
and everyone can name them, but as a generality that is true.

The other school of thought feels that you have immensely powerful client
machines accessing your site, so why not use them?  They believe that web
applications don't have to look like pages of static text with boring HTML
forms all over the place.  There are equally valid reasons for their point
of view: performance, richer user experiences and lower server utilization
(and thereby costs), etc.  They generally develop things that look, feel
and work more like fat-clients, however, they tend to be more complex,
requiring a higher degree of expertise to develop and maintain.

Both sides have valid points.  I personally fall in the later group, but I
swing to the other side sometimes (man, taken out of context my wife is
gonna KILL me!).

In any case, when you are talking about a web SITE, I think there is more
to be said for the classical camp, and just the opposite is true when
talking about a web APPLICATION.  What determines which something is? 
There are no hard and fast rules, but generally, if you are developing
something that you can't control or even know who will be accessing it,
you are developing a web SITE and you should think a different way than
someone developing something that will be accessed by a known audience. 
Note that having a known audience does NOT imply it is an internal
application, although that is true much of the time.  You can have an web
application that is outward-facing... a bank's web site is usually given
as an example of this (although some argue they wouldn't use a bank that
required then to use Javascript)... depending on what functionality that
banks' site provides, requiring Javascript might be justifiable.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 1:19 pm, Benedict, Paul C said:
> To Frank's point,
>
> I am sometimes one of those users who turn off JavaScript ;-) But, it's a
> moot point, because, as I see it, no one's website should depend on
> JavaScript for it to be fully functional anymore than it should wholly
> rely
> on CSS. These are technologies that enable powerful usability, but
> websites
> should gracefully degrade when they are not available.
>
> So Ajax should add "nice to have's", but not "must have's".
>
> -Original Message-
> From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 18, 2005 1:14 PM
> To: Struts Users Mailing List
> Cc: Struts Users Mailing List
> Subject: RE: AJAX: Whoa, Nellie!
>
>
> Users that turn off JS are akin, in my mind, to automobile drivers who
> decide they would rather play Fred Flintstone, cut holes in the
> floorboards and not bother starting the engine.  Oh, you'll get around,
> but your missing out!
>
> While I am certainly not trying to say there aren't very legitimate
> concerns with using JS, like most things they are overcome with knowledge
> and ability.  I mean, no one complains because Windows ships with fdisk
> and format, they are at least as dangerous potentially!
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Mon, April 18, 2005 1:06 pm, Fogleson, Allen said:
>> Although I will admit the usefulness overall of javascript and in
>> specific AJAX's use thereof I still have an uneasy feeling whenever you
>> are using JS. Users, in general, have become smarter security wise and
>> many are turning off JS altogether. Unfortunately there is no other
>> client side "secure" technology to replace js so I guess we are stuck
>> with it :)
>>
>> Al
>>
>> -Original Message-
>> From: Jason King [mailto:[EMAIL PROTECTED]
>> Sent: Monday, April 18, 2005 

RE: AJAX: Whoa, Nellie!

[Fogleson, Allen]

I agree, however I have worked for product companies who simply say "To
use X you MUST have javascript enabled." In fact my last company did
this. And after seeing the codebase shortly after starting there in
their services division I understood why. A choice had been made early
in the development (as in 3 or 4 versions prior to the current one) and
it dominoed. To change the product to gracefully handle people without
javascript enabled would simply have been cost prohibitive. 

On the other side of the coin I have done contracts at corporations that
turn off javascript and do not allow it to be enabled at all on their
internal (workstation) machines. 

It's a catch 22 almost. Js does allow some very cool things to be done,
but it is still a "security hole." Basically you are making requests
behind the users back in this case. And that is what security folks
start to freak out about. (can you tell I'm on a security consulting gig
right now? :)

The bottom line is really how hard it would be to "gracefully" fall back
to a full page refresh using "struts-ajax", which is basically what you
suggest.

Al


-Original Message-
From: Benedict, Paul C [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 12:19 PM
To: 'Struts Users Mailing List'
Subject: RE: AJAX: Whoa, Nellie!

To Frank's point,

I am sometimes one of those users who turn off JavaScript ;-) But, it's
a
moot point, because, as I see it, no one's website should depend on
JavaScript for it to be fully functional anymore than it should wholly
rely
on CSS. These are technologies that enable powerful usability, but
websites
should gracefully degrade when they are not available.

So Ajax should add "nice to have's", but not "must have's".


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[Jeff Beal]

Are you overriding execute() in either your Action or BaseAction? 

On 4/18/05, David Johnson <[EMAIL PROTECTED]> wrote:
> Any further insights on this? It seems I'm missing something simple here...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Fogleson, Allen]

But windows (at least in it's "newest" form - XP) doesn't ship with
fdisk anymore :) (Heck the way windows is going pretty soon you wont be
able to format either except at install time)

Al

-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 12:14 PM
To: Struts Users Mailing List
Cc: Struts Users Mailing List
Subject: RE: AJAX: Whoa, Nellie!

Users that turn off JS are akin, in my mind, to automobile drivers who
decide they would rather play Fred Flintstone, cut holes in the
floorboards and not bother starting the engine.  Oh, you'll get around,
but your missing out!

While I am certainly not trying to say there aren't very legitimate
concerns with using JS, like most things they are overcome with
knowledge
and ability.  I mean, no one complains because Windows ships with fdisk
and format, they are at least as dangerous potentially!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Benedict, Paul C]

To Frank's point,

I am sometimes one of those users who turn off JavaScript ;-) But, it's a
moot point, because, as I see it, no one's website should depend on
JavaScript for it to be fully functional anymore than it should wholly rely
on CSS. These are technologies that enable powerful usability, but websites
should gracefully degrade when they are not available.

So Ajax should add "nice to have's", but not "must have's".

-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 1:14 PM
To: Struts Users Mailing List
Cc: Struts Users Mailing List
Subject: RE: AJAX: Whoa, Nellie!


Users that turn off JS are akin, in my mind, to automobile drivers who
decide they would rather play Fred Flintstone, cut holes in the
floorboards and not bother starting the engine.  Oh, you'll get around,
but your missing out!

While I am certainly not trying to say there aren't very legitimate
concerns with using JS, like most things they are overcome with knowledge
and ability.  I mean, no one complains because Windows ships with fdisk
and format, they are at least as dangerous potentially!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 1:06 pm, Fogleson, Allen said:
> Although I will admit the usefulness overall of javascript and in
> specific AJAX's use thereof I still have an uneasy feeling whenever you
> are using JS. Users, in general, have become smarter security wise and
> many are turning off JS altogether. Unfortunately there is no other
> client side "secure" technology to replace js so I guess we are stuck
> with it :)
>
> Al
>
> -Original Message-
> From: Jason King [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 18, 2005 11:56 AM
> To: Struts Users Mailing List
> Subject: Re: AJAX: Whoa, Nellie!
>
> As soon as IE becomes open source we can start that.  Until then, or
> until IE's market share drops into single digits we're forced to deal
> with browsers as a given.  Besides, much of the visceral dislike for
> javascript is based on older browsers that were not at all consistend.
> Trying to write cross-browser IE4-NS4 javascript is often an exercise in
>
> frustration.  In the IE6 - Moz 1.7 Firefox 1.0x (sorry I'm not a Mac guy
>
> so I don't know the current ver for its browser) most problems can be
> avoided by using DOM compliant code rather than IE specific code.  This
> ain't yer daddy's DHTML.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Notice:  This e-mail message, together with any attachments, contains 
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New 
Jersey, USA 08889), and/or its affiliates (which may be known outside the 
United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as 
Banyu) that may be confidential, proprietary copyrighted and/or legally 
privileged. It is intended solely for the use of the individual or entity named 
on this message.  If you are not the intended recipient, and have received this 
message in error, please notify us immediately by reply e-mail and then delete 
it from your system.
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

Javascript hasn't been a problem as far as cross-browser development goes
for some time, in my experience anyway.  I can't remember the last time I
wrote code that worked on one browser and not another.

Oh wait, I take that back... I remember something about IE's substring
method not working like Netscapes.

But, as Jason said, if you are using modern versions, or even relatively
recent ones, you probably won't have any problems as far as the scripting
goes.

The DOM models still have a fair degree of different, that's where you can
sometimes run in to problems.  Yes, coding to standard DOM will cut that
down a bit, but even still you'll have to think lowest common denominator
sometimes.

The days of huge code branches and/or whole different code bases are,
thankfully, gone (well, largely gone anyway).  Some minor branching here
or there, while annoying, are far from the problems we used to have in any
case.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 12:55 pm, Jason King said:
> Woodchuck wrote:
> As soon as IE becomes open source we can start that.  Until then, or
> until IE's market share drops into single digits we're forced to deal
> with browsers as a given.  Besides, much of the visceral dislike for
> javascript is based on older browsers that were not at all consistend.
> Trying to write cross-browser IE4-NS4 javascript is often an exercise in
> frustration.  In the IE6 - Moz 1.7 Firefox 1.0x (sorry I'm not a Mac guy
> so I don't know the current ver for its browser) most problems can be
> avoided by using DOM compliant code rather than IE specific code.  This
> ain't yer daddy's DHTML.
>
>>sorry, i couldn't resist >.<
>>
>>actually, why don't we address this problem at the source rather than
>>using this javascript patch solution?  (at least this is how i see it)
>>
>>why don't the browser makers build internal mechanisms to allow posting
>>of forms without the need to refresh the html page?  why don't we
>>re-architect the browswer and address this problem (and others) at that
>>fundamental level?
>>
>>is this not conceivable?
>>
>>woodchuck
>>
>>
>>--- Dakota Jack <[EMAIL PROTECTED]> wrote:
>>
>>
>>>JavaScript provides a client side rather developed engine in
>>>JavaScript as well as Flash, etc.  This is merely a resource.  The
>>>"yuck, ptooey! ptooey" response to these ideas, especially ones in
>>>production and successful for quite a while, strikes me as rather
>>>less
>>>than professional.  I think it is interesting that JavaScript, which
>>>I
>>>have avoided like the plague, has kept building a market despite a
>>>lot
>>>of prejudice from people like myself, not to mention Woodchuck.
>>>///;-)
>>>
>>>On 4/18/05, Woodchuck <[EMAIL PROTECTED]> wrote:
>>>
>>>
eee... javascript...

yuck, ptooey! ptooey!!


--- "Vic Cekvenich (netsql)" <[EMAIL PROTECTED]> wrote:


>Stéphane Zuckerman wrote:
>  if this were to be integrated in Struts,
>
>
>>my life would be easier.
>>
>>
>I too will now check it out.
>
>.V
>
>
>
>
>
>>>-
>>>
>>>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
__
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide




>>>-
>>>
>>>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




>>>--
>>>"You can lead a horse to water but you cannot make it float on its
>>>back."
>>>~Dakota Jack~
>>>
>>>-
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>>
>>
>>
>>
>>__
>>Do you Yahoo!?
>>Plan great trips with Yahoo! Travel: Now over 17,000 guides!
>>http://travel.yahoo.com/p-travelguide
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

Users that turn off JS are akin, in my mind, to automobile drivers who
decide they would rather play Fred Flintstone, cut holes in the
floorboards and not bother starting the engine.  Oh, you'll get around,
but your missing out!

While I am certainly not trying to say there aren't very legitimate
concerns with using JS, like most things they are overcome with knowledge
and ability.  I mean, no one complains because Windows ships with fdisk
and format, they are at least as dangerous potentially!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 1:06 pm, Fogleson, Allen said:
> Although I will admit the usefulness overall of javascript and in
> specific AJAX's use thereof I still have an uneasy feeling whenever you
> are using JS. Users, in general, have become smarter security wise and
> many are turning off JS altogether. Unfortunately there is no other
> client side "secure" technology to replace js so I guess we are stuck
> with it :)
>
> Al
>
> -Original Message-
> From: Jason King [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 18, 2005 11:56 AM
> To: Struts Users Mailing List
> Subject: Re: AJAX: Whoa, Nellie!
>
> As soon as IE becomes open source we can start that.  Until then, or
> until IE's market share drops into single digits we're forced to deal
> with browsers as a given.  Besides, much of the visceral dislike for
> javascript is based on older browsers that were not at all consistend.
> Trying to write cross-browser IE4-NS4 javascript is often an exercise in
>
> frustration.  In the IE6 - Moz 1.7 Firefox 1.0x (sorry I'm not a Mac guy
>
> so I don't know the current ver for its browser) most problems can be
> avoided by using DOM compliant code rather than IE specific code.  This
> ain't yer daddy's DHTML.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Fogleson, Allen]

Although I will admit the usefulness overall of javascript and in
specific AJAX's use thereof I still have an uneasy feeling whenever you
are using JS. Users, in general, have become smarter security wise and
many are turning off JS altogether. Unfortunately there is no other
client side "secure" technology to replace js so I guess we are stuck
with it :)

Al

-Original Message-
From: Jason King [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 11:56 AM
To: Struts Users Mailing List
Subject: Re: AJAX: Whoa, Nellie!

As soon as IE becomes open source we can start that.  Until then, or 
until IE's market share drops into single digits we're forced to deal 
with browsers as a given.  Besides, much of the visceral dislike for 
javascript is based on older browsers that were not at all consistend.  
Trying to write cross-browser IE4-NS4 javascript is often an exercise in

frustration.  In the IE6 - Moz 1.7 Firefox 1.0x (sorry I'm not a Mac guy

so I don't know the current ver for its browser) most problems can be 
avoided by using DOM compliant code rather than IE specific code.  This 
ain't yer daddy's DHTML.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Jason King]

Woodchuck wrote:
As soon as IE becomes open source we can start that.  Until then, or 
until IE's market share drops into single digits we're forced to deal 
with browsers as a given.  Besides, much of the visceral dislike for 
javascript is based on older browsers that were not at all consistend.  
Trying to write cross-browser IE4-NS4 javascript is often an exercise in 
frustration.  In the IE6 - Moz 1.7 Firefox 1.0x (sorry I'm not a Mac guy 
so I don't know the current ver for its browser) most problems can be 
avoided by using DOM compliant code rather than IE specific code.  This 
ain't yer daddy's DHTML.

sorry, i couldn't resist >.<
actually, why don't we address this problem at the source rather than
using this javascript patch solution?  (at least this is how i see it)
why don't the browser makers build internal mechanisms to allow posting
of forms without the need to refresh the html page?  why don't we
re-architect the browswer and address this problem (and others) at that
fundamental level?
is this not conceivable?
woodchuck
--- Dakota Jack <[EMAIL PROTECTED]> wrote:
 

JavaScript provides a client side rather developed engine in
JavaScript as well as Flash, etc.  This is merely a resource.  The
"yuck, ptooey! ptooey" response to these ideas, especially ones in
production and successful for quite a while, strikes me as rather
less
than professional.  I think it is interesting that JavaScript, which
I
have avoided like the plague, has kept building a market despite a
lot
of prejudice from people like myself, not to mention Woodchuck. 
///;-)

On 4/18/05, Woodchuck <[EMAIL PROTECTED]> wrote:
   

eee... javascript...
yuck, ptooey! ptooey!!
--- "Vic Cekvenich (netsql)" <[EMAIL PROTECTED]> wrote:
 

Stéphane Zuckerman wrote:
 if this were to be integrated in Struts,
   

my life would be easier.
 

I too will now check it out.
.V

   

-
   

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   

__
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide
 

-
   

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

--
"You can lead a horse to water but you cannot make it float on its
back."
~Dakota Jack~
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   


		
__ 
Do you Yahoo!? 
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

On Mon, April 18, 2005 11:33 am, Hubert Rabago said:
> No problemo.  As far as the extension itself is concerned, I'd still
> be interested in it, but like I mentioned earlier, only as a plugin
> that doesn't change the base tags.

I thought that was a fair point at the time, and still do.  I haven't had
time to look into it yet, but I wouldn't mind re-implementing what I've
done as the EL tags are, as you pointed out, just an extension.  I have
some questions on how to actually do it, but the idea I think is sound.

> The reasons are many and they are
> mentioned in the dev thread you started.  My main concern is
> implementation lock-in.  Another message in this thread already
> illustrates that there could be several approaches to adding this
> functionality.  I wouldn't want to limit how everyone else applies the
> technology.

Absolutely.  I was trying to provide an easy way for people to get started
with AJAX techniques while still using the tags they are already familiar
with, that was my underlying thought.  But the objections raised where
perfectly valid.  I do think the extension approach addresses those
concerns, and hopefully I'll have some time to go that route.

> As Martin said, if an implementation is built into
> Struts, it should support whatever client-side library the developer
> would want to use (
> http://marc.theaimsgroup.com/?l=struts-dev&m=111284722931074&w=2 ).  A
> separate plugin wouldn't have to have that burden.

I was actually a bit perplexed by Martin's reply... I still am I guess...
when we talk about supporting "whatever client-side library the developer
wants to use", what are we really talking about?  I've always thought that
if you use the Struts tags, you have in effect choosen what client-side
library you are using.  If you were to use JSF or whatever else you could
name, wouldn't you be using a whole different set of tags, that may or may
not have AJAX functionality?

I guess I'd like to hear that point clarified... what does everyone think
it actually means to support a client-side library?  Perhaps starting with
really defining what a client-side library is would be a good starting
point :)

> A separated plugin would result in code duplication, true, but in my
> view it's worth it.  In some aspects, the ajax-aware tags you propose
> are in a better position than the EL tags.  You only need to override
> some methods, whose implementation can be moved to a util-type class.
> EL had to add duplicate fields, getters, and setters.  Just take a
> look at the source of some of those tags, like ELCheckboxTag and
> ELRadioTag.

I do agree, for my initial simple pass, that is a better way to go.  I
didn't do that mainly because of what you say: code duplication.  But,
that probably is ultimately a better answer.  Like I said, there are some
questions in my mind how you mechanically go about it, but the idea is
sound I think.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

Interesting... honestly, I hadn't thought about it!

I think you kind of touch on one of the points made in the dev list thread
(by Martin I believe) that was cited as a reason not to go with my
proposal: is it flexible enough?  Certainly it would be next to impossible
to cover ever usage pattern, and it might be folly to try.  This might be
along those lines... if we tried to tie in to the form errors, we would
necasserily have to choose one implementation or another, and then you've
tied everyone to that.  It's a fair point I think.

My argument was that providing at least a simple implementation, assuming
it could be extended later, made sense.  That was actully my argument for
the whole proposal... I don't think it would have been the One True
Solution to bind us all, but for those that are just coming into the AJAX
mindset, it gives them an easy way into it, and then later on when they
need more power and flexibility they can move on to something better.

Of course, there are rather reasonable arguments against even THAT :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 11:15 am, Benedict, Paul C said:
> Frank, will Ajax support be tied into reporting form errors? It would be
> interesting to break down the validator into individual validations, so
> errors can be reported to the user as he types.
>
> -Original Message-
> From: Emmanouil Batsis [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 18, 2005 11:12 AM
> To: Struts Users Mailing List; Dakota Jack
> Subject: Re: AJAX: Whoa, Nellie!
>
>
>
> Let me first say that IMHO, introducing AJAX capabilities into the html
> taglib is an awesome idea.
>
> Frank W. Zammetti wrote:
>
>>So, the question is, does anyone see this as something interesting?
>>
> Very. I was also thinking about working on AJAX taglibs using Sarissa
> [1] (introductory article at [2]), but i was aiming for more than
> XMLHttpRequest, for example to allow XSLT transformations to be applied
> on the XML either the server or client, depending on what the browser
> supports.
>
>> Is anyone interested in seeing this actually finished up?  If so I can
>> do
>>that, probably by the weekend if things go well, and I suppose open a
>>ticket for it at that point.
>>
>>
>
> I would happily help (although i have little time) and even donate the
> JS code under the ASL if wanted.
>
>>Questions?  Comments?  Whatever?  Thanks all!
>>
>
> I haven't really studied the samples yet, but it would seem more
> semantically correct to me if the html:form was used to make this work.
> I'll try to come up with more concrete suggestions.
>
> [1] http://sarissa.sf.net/
> [2] http://www.xml.com/pub/a/2005/02/23/sarissa.html
>
> Manos
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> --
> Notice:  This e-mail message, together with any attachments, contains
> information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New
> Jersey, USA 08889), and/or its affiliates (which may be known outside the
> United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as
> Banyu) that may be confidential, proprietary copyrighted and/or legally
> privileged. It is intended solely for the use of the individual or entity
> named on this message.  If you are not the intended recipient, and have
> received this message in error, please notify us immediately by reply
> e-mail and then delete it from your system.
> --
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

On Mon, April 18, 2005 11:12 am, Emmanouil Batsis said:
> I haven't really studied the samples yet, but it would seem more
> semantically correct to me if the html:form was used to make this work.
> I'll try to come up with more concrete suggestions.

I thought of that too, but what changed my mind is the question of how do
you handle it if you want to have a number of different elements doing
different things.  For instance, if you have three  elements and
you want one to populate a  with text retrieved from the server
when changed, another to pop up an alert with a message from the server
when changed, and the other to go to the URL selected with a query string
appended on that is generated by the server when changed... If the
functionality was tied to the form, how would you allow for that?

I think doing it at the individual form element level allows for more
flexibility, although I see your point about what seems semantically
correct.  I'm open to suggestions either way.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[K.C. Baltz]

Be sure to check out SWF (https://swf.dev.java.net/).
It includes In place Page Updating (through AJAX) by the use of tags.  
Their approach is somewhat brute force (the whole page is rendered on 
the server and only the parts that are marked for updating are sent to 
the client), but it's easy to drop in.  They've even got "Struts 
integration" although they really don't seem to depend on Struts at all 
for that. 

I was able to easily add a small query tool to a page that I didn't want 
to fully refresh. 

They posted an announcement to this list a week or two ago.  Search for 
that as it has some instructions on setting up SWF to work with Struts.

K.C. Baltz
Dakota Jack wrote:
I have been taking another look at the AJAX stuff that Frank Zammetti
has provided.  This stuff is revolutionary.  Someone ought to be
taking a close look at integrating such solutions, so far as it makes
sense, into Struts.  This is not a passing fancy, in my estimation. 
This is a real solution to a persistent problem.  Further, this moves
the solution to where the problem exists, on the client.  I, for one,
am getting excited.  I am not saying to be precipitous, so the usual
mundane warnings can be kept aside.  But, this is not the usual thing.
This is a fundamental shift in architecture that makes clear sense.

Jack
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

html:multibox

[Riyaz Mansoor]

hi

reading from past postings this subject has been much talked about.
but not finding a solution to my liking i post this question.

i want a user a see a set of checkboxes some selected some not. the
user is allowed to check uncheck anyone of them.

upon form submission, i want the value of the checkbox which can be
any value of type int to be submitted as an array to form. ie the
value can be (1,2,3 ... 1000,1001,10...). also, is it possible
to check a checkbox for any of these vales?

my form : DynaActinForm has fields

id:integer // not given here
selected:integer[]
all:integer[]

ok: now am trouble in jsp ;(

also, for form prepopulation, is it possible to set the selected,all
array types with

form.set("propname", index, ValueObject);

does the form take care of the "increasing index" ??

thanx
riyaz

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

example using validations with nested tags

[kjc]

Does anyone know of any examples using the struts validation framework 
with the nested tags.

Thanks in advance.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatch Action Strangeness

[David Johnson]

Any further insights on this? It seems I'm missing something simple here...

I dont want ot have to manually call methods on my action...

help?  :)

Is there something beyond the



that I need (and the hidden field named "dispatch")

and of course to have my Action inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from it... that wouldnt make a diffference though correct?

On 4/15/05, David Johnson <[EMAIL PROTECTED]> wrote:
> in my HTML I have
> 
> 
> 
> in my struts config (for the appropriate action) I have
> 
> parameter="dispatch"
> 
> Is there something else I need?
> 
> On 4/15/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> > David Johnson wrote the following on 4/15/2005 3:21 PM:
> > > I saw that after I sent it. I have changed it to inherit from
> > > org.apache.struts.actions.DispatchAction (actually my BaseAction
> > > inherits from DispatchAction) but the methods still arent being
> > > called.
> >
> > You sure you have the parameter property in your action mapping in your
> > struts config?
> >
> > "set('graph'); I'm assuming is setting a hidden parameter (your dispatch
> > parameter)... whatever that parameter is, is the one you need also
> > defined in your action mapping.
> >
> > --
> > Rick
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> --
> -Dave
> [EMAIL PROTECTED]
> 


-- 
-Dave
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Dakota Jack]

On 4/18/05, Dave Newton <[EMAIL PROTECTED]> wrote:

> Or we could just use ActiveX controls.
> 
> *psych!*


Or JavaScript, or Applets, or Flash, or .. but,
most importantly, in this thread, AJAX with STRUTS.

Jack

-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [OT] For Struts or Sports Lovers

[Pilgrim, Peter]

Might have helped to have a guest login "guest/guest123"

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497


> -Original Message-
> From: t t [mailto:[EMAIL PROTECTED]
> Sent: 15 April 2005 17:21
> To: user@struts.apache.org
> Subject: [OT] For Struts or Sports Lovers
> 
> 
> If you are a struts or sports lover or both, you're welcome 
> to take a look at www.sportslovers.net which is a yellow page 
> of sports lovers and built based on Struts. 
> Sorry if this post bothers you.
>  
> T.T.
>   
> -
> Do you Yahoo!?
>  Yahoo! Small Business - Try our new resources site! 
> 

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Hubert Rabago]

No problemo.  As far as the extension itself is concerned, I'd still
be interested in it, but like I mentioned earlier, only as a plugin
that doesn't change the base tags.  The reasons are many and they are
mentioned in the dev thread you started.  My main concern is
implementation lock-in.  Another message in this thread already
illustrates that there could be several approaches to adding this
functionality.  I wouldn't want to limit how everyone else applies the
technology.  As Martin said, if an implementation is built into
Struts, it should support whatever client-side library the developer
would want to use (
http://marc.theaimsgroup.com/?l=struts-dev&m=111284722931074&w=2 ).  A
separate plugin wouldn't have to have that burden.

A separated plugin would result in code duplication, true, but in my
view it's worth it.  In some aspects, the ajax-aware tags you propose
are in a better position than the EL tags.  You only need to override
some methods, whose implementation can be moved to a util-type class. 
EL had to add duplicate fields, getters, and setters.  Just take a
look at the source of some of those tags, like ELCheckboxTag and
ELRadioTag.

Hubert


On 4/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Yep, sorry about that... I had it in my drafts folder because I got called
> away in the middle of it, and I didn't check all the replies to the
> current thread before sending it so I didn't see your link until
> afterwards.  My bad :)
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> On Mon, April 18, 2005 10:41 am, Hubert Rabago said:
> > Frank,
> >
> > You must've started typing this response a while ago.  I already sent
> > a message on this thread linking to the dev email with your proposal.
> >
> > Hubert
> >
> > On 4/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> >> On 4/6 I posted the following message to the Struts dev list... I can't
> >> seem to find the thread in the list archives, if anyone else can I would
> >> appreciate very much you posting the link to it...
> >>
> >> This was discussing my proposal for integrating AJAX functionality into
> >> the existing Struts taglibs.  There were some legitimate dissenting
> >> points
> >> raised about this, and ultimately the idea was shot down.  However, I
> >> still feel the idea has significant merit.
> >>
> >> The proposal wasn't posted to the user list, and maybe I should have
> >> done
> >> so... if there is support for this in the user community, I would be
> >> willing to persue it further and provide it as part of the SF Struts
> >> project.
> >>
> >> P.S., I've added some notes here for some things that may not be as
> >> clear
> >> as I would have liked, especially if you aren't terribly familiar with
> >> the
> >> Struts code base, so if you see minor difference between this and what
> >> is
> >> in the archives, that's all it is...
> >>
> >> 
> >>
> >> Subject: RFC: Struts HTML Ajax-Aware Tags
> >>
> >> Afternoon all,
> >>
> >> Please reference the code at:
> >>
> >> http://www.omnytex.com/ajaxtags.zip
> >>
> >> This is a complete webapp demonstrating the proposal (it isn't complete,
> >> it is just to get the ideas across).
> >>
> >> I wanted to put something out there in front of you all and get some
> >> feedback on it before I go that extra mile and finish it out.
> >>
> >> This came out of some ideas I tossed at Ted a few days ago.  The basic
> >> idea is to take the existing Struts HTML taglib and make the tags
> >> Ajax-aware.
> >>
> >> In a nuthsell, take a simple button tag...
> >>
> >> 
> >>
> >> ...now, add a new attribute to it, ajaxRef:
> >>
> >>  >> ajaxRef="button1" />
> >>
> >> When the tag is rendered, each possible type of event handler (in the
> >> BaseTagHandler class) looks something like this now:
> >>
> >> if (getOnclick() != null) {
> >> handlers.append(" onclick=\"");
> >> handlers.append(getOnclick());
> >> handlers.append("\"");
> >> }
> >> else {
> >>   prepareAjax("onclick", handlers);
> >> }
> >>
> >> prepareAjax() does a lookup to a new XML configuration file (well,
> >> in-memory objects representing the XML of course!) like so:
> >>
> >> 
> >>   
> >> button1
> >> 
> >>   onClick
> >>   queryString
> >>   buttonValue=button1,textValue=text1
> >>   http://www.omnytex.com
> >>   stdInnerHTML
> >>   resultLayer
> >> 
> >>   
> >> 
> >>
> >> If an  with an  matching the ajaxRef attribute is
> >> found,
> >> and if an  with a  matching the type being added to the tag
> >> is found, then the prepareAjax() method does its thing (note that
> >> developer-defined event handler functions will take precedent, so no
> >> existing code would be broken by this).  And what is "its thing" you
> >> ask?
> >>
> >> Basically it will add an inline event handler to the tag, just like
> >> always, that is capable of making an Ajax request (using the
> >> XMLHttpRequest c

Re: AJAX: Whoa, Nellie!

[Dakota Jack]

Not sure what to say, Woodchuck, about your suggestion that a request
be sent that does not want a response and does not affect the HTML
page.  What would happen next?  And, how?  This is perfectly
conceivable.  Heck, I think that it might be possible as is.  But, I
don't see this as even addressing the problem that AJAX is so "neato,
keen" on.

Jack

On 4/18/05, Woodchuck <[EMAIL PROTECTED]> wrote:
> sorry, i couldn't resist >.<
> 
> actually, why don't we address this problem at the source rather than
> using this javascript patch solution?  (at least this is how i see it)
> 
> why don't the browser makers build internal mechanisms to allow posting
> of forms without the need to refresh the html page?  why don't we
> re-architect the browswer and address this problem (and others) at that
> fundamental level?
> 
> is this not conceivable?
> 
> woodchuck
> 
> 
> --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > JavaScript provides a client side rather developed engine in
> > JavaScript as well as Flash, etc.  This is merely a resource.  The
> > "yuck, ptooey! ptooey" response to these ideas, especially ones in
> > production and successful for quite a while, strikes me as rather
> > less
> > than professional.  I think it is interesting that JavaScript, which
> > I
> > have avoided like the plague, has kept building a market despite a
> > lot
> > of prejudice from people like myself, not to mention Woodchuck.
> > ///;-)
> >
> > On 4/18/05, Woodchuck <[EMAIL PROTECTED]> wrote:
> > > eee... javascript...
> > >
> > > yuck, ptooey! ptooey!!
> > >
> > >
> > > --- "Vic Cekvenich (netsql)" <[EMAIL PROTECTED]> wrote:
> > > > Stéphane Zuckerman wrote:
> > > >   if this were to be integrated in Struts,
> > > > > my life would be easier.
> > > >
> > > > I too will now check it out.
> > > >
> > > > .V
> > > >
> > > >
> > > >
> > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > __
> > > Do you Yahoo!?
> > > Plan great trips with Yahoo! Travel: Now over 17,000 guides!
> > > http://travel.yahoo.com/p-travelguide
> > >
> > >
> > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > "You can lead a horse to water but you cannot make it float on its
> > back."
> > ~Dakota Jack~
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> __
> Do you Yahoo!?
> Plan great trips with Yahoo! Travel: Now over 17,000 guides!
> http://travel.yahoo.com/p-travelguide
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Dave Newton]

Woodchuck wrote:
why don't the browser makers build internal mechanisms to allow posting
of forms without the need to refresh the html page?  why don't we
re-architect the browswer and address this problem (and others) at that
fundamental level?
is this not conceivable?
 

Anything is conceivable. Most web developers have ben railing on the... 
irritating nature of browser-based apps for a Really Long Time now.

However, many of us would like to have cool web apps today rather than 
the 2-3 years that would require ;)

Or we could just use ActiveX controls.
*psych!*
Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX: Whoa, Nellie!

[Benedict, Paul C]

Frank, will Ajax support be tied into reporting form errors? It would be
interesting to break down the validator into individual validations, so
errors can be reported to the user as he types.

-Original Message-
From: Emmanouil Batsis [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 11:12 AM
To: Struts Users Mailing List; Dakota Jack
Subject: Re: AJAX: Whoa, Nellie!



Let me first say that IMHO, introducing AJAX capabilities into the html 
taglib is an awesome idea.

Frank W. Zammetti wrote:

>So, the question is, does anyone see this as something interesting? 
>
Very. I was also thinking about working on AJAX taglibs using Sarissa 
[1] (introductory article at [2]), but i was aiming for more than 
XMLHttpRequest, for example to allow XSLT transformations to be applied 
on the XML either the server or client, depending on what the browser 
supports.

> Is anyone interested in seeing this actually finished up?  If so I can do
>that, probably by the weekend if things go well, and I suppose open a
>ticket for it at that point.
>  
>

I would happily help (although i have little time) and even donate the 
JS code under the ASL if wanted.

>Questions?  Comments?  Whatever?  Thanks all!
>

I haven't really studied the samples yet, but it would seem more 
semantically correct to me if the html:form was used to make this work. 
I'll try to come up with more concrete suggestions.

[1] http://sarissa.sf.net/
[2] http://www.xml.com/pub/a/2005/02/23/sarissa.html

Manos




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Notice:  This e-mail message, together with any attachments, contains 
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New 
Jersey, USA 08889), and/or its affiliates (which may be known outside the 
United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as 
Banyu) that may be confidential, proprietary copyrighted and/or legally 
privileged. It is intended solely for the use of the individual or entity named 
on this message.  If you are not the intended recipient, and have received this 
message in error, please notify us immediately by reply e-mail and then delete 
it from your system.
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

html:link and html:cancel

[Abdullah Jibaly]

Hi all,

Is there a way to use html:link in a way that it acts like html:cancel, in 
other words automatically skip validation?

This seems to work but I wonder if there is a better way?




Cancel




Thanks,
Abdullah

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Woodchuck]

sorry, i couldn't resist >.<

actually, why don't we address this problem at the source rather than
using this javascript patch solution?  (at least this is how i see it)

why don't the browser makers build internal mechanisms to allow posting
of forms without the need to refresh the html page?  why don't we
re-architect the browswer and address this problem (and others) at that
fundamental level?

is this not conceivable?

woodchuck


--- Dakota Jack <[EMAIL PROTECTED]> wrote:
> JavaScript provides a client side rather developed engine in
> JavaScript as well as Flash, etc.  This is merely a resource.  The
> "yuck, ptooey! ptooey" response to these ideas, especially ones in
> production and successful for quite a while, strikes me as rather
> less
> than professional.  I think it is interesting that JavaScript, which
> I
> have avoided like the plague, has kept building a market despite a
> lot
> of prejudice from people like myself, not to mention Woodchuck. 
> ///;-)
> 
> On 4/18/05, Woodchuck <[EMAIL PROTECTED]> wrote:
> > eee... javascript...
> > 
> > yuck, ptooey! ptooey!!
> > 
> > 
> > --- "Vic Cekvenich (netsql)" <[EMAIL PROTECTED]> wrote:
> > > Stéphane Zuckerman wrote:
> > >   if this were to be integrated in Struts,
> > > > my life would be easier.
> > >
> > > I too will now check it out.
> > >
> > > .V
> > >
> > >
> > >
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > 
> > __
> > Do you Yahoo!?
> > Plan great trips with Yahoo! Travel: Now over 17,000 guides!
> > http://travel.yahoo.com/p-travelguide
> > 
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 
> -- 
> "You can lead a horse to water but you cannot make it float on its
> back."
> ~Dakota Jack~
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 



__ 
Do you Yahoo!? 
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Emmanouil Batsis]

Let me first say that IMHO, introducing AJAX capabilities into the html 
taglib is an awesome idea.

Frank W. Zammetti wrote:
So, the question is, does anyone see this as something interesting? 

Very. I was also thinking about working on AJAX taglibs using Sarissa 
[1] (introductory article at [2]), but i was aiming for more than 
XMLHttpRequest, for example to allow XSLT transformations to be applied 
on the XML either the server or client, depending on what the browser 
supports.

Is anyone interested in seeing this actually finished up?  If so I can do
that, probably by the weekend if things go well, and I suppose open a
ticket for it at that point.
 

I would happily help (although i have little time) and even donate the 
JS code under the ASL if wanted.

Questions?  Comments?  Whatever?  Thanks all!
I haven't really studied the samples yet, but it would seem more 
semantically correct to me if the html:form was used to make this work. 
I'll try to come up with more concrete suggestions.

[1] http://sarissa.sf.net/
[2] http://www.xml.com/pub/a/2005/02/23/sarissa.html
Manos

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Dakota Jack]

JavaScript provides a client side rather developed engine in
JavaScript as well as Flash, etc.  This is merely a resource.  The
"yuck, ptooey! ptooey" response to these ideas, especially ones in
production and successful for quite a while, strikes me as rather less
than professional.  I think it is interesting that JavaScript, which I
have avoided like the plague, has kept building a market despite a lot
of prejudice from people like myself, not to mention Woodchuck. 
///;-)

On 4/18/05, Woodchuck <[EMAIL PROTECTED]> wrote:
> eee... javascript...
> 
> yuck, ptooey! ptooey!!
> 
> 
> --- "Vic Cekvenich (netsql)" <[EMAIL PROTECTED]> wrote:
> > Stéphane Zuckerman wrote:
> >   if this were to be integrated in Struts,
> > > my life would be easier.
> >
> > I too will now check it out.
> >
> > .V
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> __
> Do you Yahoo!?
> Plan great trips with Yahoo! Travel: Now over 17,000 guides!
> http://travel.yahoo.com/p-travelguide
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

Yep, sorry about that... I had it in my drafts folder because I got called
away in the middle of it, and I didn't check all the replies to the
current thread before sending it so I didn't see your link until
afterwards.  My bad :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 10:41 am, Hubert Rabago said:
> Frank,
>
> You must've started typing this response a while ago.  I already sent
> a message on this thread linking to the dev email with your proposal.
>
> Hubert
>
> On 4/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>> On 4/6 I posted the following message to the Struts dev list... I can't
>> seem to find the thread in the list archives, if anyone else can I would
>> appreciate very much you posting the link to it...
>>
>> This was discussing my proposal for integrating AJAX functionality into
>> the existing Struts taglibs.  There were some legitimate dissenting
>> points
>> raised about this, and ultimately the idea was shot down.  However, I
>> still feel the idea has significant merit.
>>
>> The proposal wasn't posted to the user list, and maybe I should have
>> done
>> so... if there is support for this in the user community, I would be
>> willing to persue it further and provide it as part of the SF Struts
>> project.
>>
>> P.S., I've added some notes here for some things that may not be as
>> clear
>> as I would have liked, especially if you aren't terribly familiar with
>> the
>> Struts code base, so if you see minor difference between this and what
>> is
>> in the archives, that's all it is...
>>
>> 
>>
>> Subject: RFC: Struts HTML Ajax-Aware Tags
>>
>> Afternoon all,
>>
>> Please reference the code at:
>>
>> http://www.omnytex.com/ajaxtags.zip
>>
>> This is a complete webapp demonstrating the proposal (it isn't complete,
>> it is just to get the ideas across).
>>
>> I wanted to put something out there in front of you all and get some
>> feedback on it before I go that extra mile and finish it out.
>>
>> This came out of some ideas I tossed at Ted a few days ago.  The basic
>> idea is to take the existing Struts HTML taglib and make the tags
>> Ajax-aware.
>>
>> In a nuthsell, take a simple button tag...
>>
>> 
>>
>> ...now, add a new attribute to it, ajaxRef:
>>
>> > ajaxRef="button1" />
>>
>> When the tag is rendered, each possible type of event handler (in the
>> BaseTagHandler class) looks something like this now:
>>
>> if (getOnclick() != null) {
>> handlers.append(" onclick=\"");
>> handlers.append(getOnclick());
>> handlers.append("\"");
>> }
>> else {
>>   prepareAjax("onclick", handlers);
>> }
>>
>> prepareAjax() does a lookup to a new XML configuration file (well,
>> in-memory objects representing the XML of course!) like so:
>>
>> 
>>   
>> button1
>> 
>>   onClick
>>   queryString
>>   buttonValue=button1,textValue=text1
>>   http://www.omnytex.com
>>   stdInnerHTML
>>   resultLayer
>> 
>>   
>> 
>>
>> If an  with an  matching the ajaxRef attribute is
>> found,
>> and if an  with a  matching the type being added to the tag
>> is found, then the prepareAjax() method does its thing (note that
>> developer-defined event handler functions will take precedent, so no
>> existing code would be broken by this).  And what is "its thing" you
>> ask?
>>
>> Basically it will add an inline event handler to the tag, just like
>> always, that is capable of making an Ajax request (using the
>> XMLHttpRequest component).  A quick description of the XML elements
>> pertaining to  should bring this in to focus:
>>
>> type .. is of course the type of event handler.  It can be any of the
>> types that the BaseHandlerTag handles.
>>
>> submitType .. is the type of submission that will be made.  Two types
>> are
>> (will be) supported: queryString and XML.
>>
>> submitItems .. is a comma-separated list of form elements and the names
>> they should be given.  For instance, in the example above we would get a
>> query string in the form ?buttonValue=<1>&textValue=<2> where <1> is the
>> value of the button on the page and <2> is the value of the textbox on
>> the
>> page.
>>
>> submitTarget .. is the URL the request is submitted to.  This can be a
>> relative path or a full URL (although full URLs will of course incur the
>> cross-site scripting restrictions)
>>
>> returnAction .. is what will happen when the request returns.  There
>> will
>> be a number of built-in actions, all prefixed with "std' (let's get all
>> the disease jokes out of the way now!).  You can also name a page-level
>> Javascript function here to do other things.
>>
>> returnTargets .. is a comma-separated list of elements on the page that
>> will be affected by the action.  This will generally be required for the
>> standard actions, and is up to the developer if they want it if writing
>> their own function.
>>
>> The code you hopefully downloaded is a sample webapp, very simpl

Re: AJAX: Whoa, Nellie!

[Hubert Rabago]

Frank,

You must've started typing this response a while ago.  I already sent
a message on this thread linking to the dev email with your proposal.

Hubert

On 4/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> On 4/6 I posted the following message to the Struts dev list... I can't
> seem to find the thread in the list archives, if anyone else can I would
> appreciate very much you posting the link to it...
> 
> This was discussing my proposal for integrating AJAX functionality into
> the existing Struts taglibs.  There were some legitimate dissenting points
> raised about this, and ultimately the idea was shot down.  However, I
> still feel the idea has significant merit.
> 
> The proposal wasn't posted to the user list, and maybe I should have done
> so... if there is support for this in the user community, I would be
> willing to persue it further and provide it as part of the SF Struts
> project.
> 
> P.S., I've added some notes here for some things that may not be as clear
> as I would have liked, especially if you aren't terribly familiar with the
> Struts code base, so if you see minor difference between this and what is
> in the archives, that's all it is...
> 
> 
> 
> Subject: RFC: Struts HTML Ajax-Aware Tags
> 
> Afternoon all,
> 
> Please reference the code at:
> 
> http://www.omnytex.com/ajaxtags.zip
> 
> This is a complete webapp demonstrating the proposal (it isn't complete,
> it is just to get the ideas across).
> 
> I wanted to put something out there in front of you all and get some
> feedback on it before I go that extra mile and finish it out.
> 
> This came out of some ideas I tossed at Ted a few days ago.  The basic
> idea is to take the existing Struts HTML taglib and make the tags
> Ajax-aware.
> 
> In a nuthsell, take a simple button tag...
> 
> 
> 
> ...now, add a new attribute to it, ajaxRef:
> 
>  ajaxRef="button1" />
> 
> When the tag is rendered, each possible type of event handler (in the
> BaseTagHandler class) looks something like this now:
> 
> if (getOnclick() != null) {
> handlers.append(" onclick=\"");
> handlers.append(getOnclick());
> handlers.append("\"");
> }
> else {
>   prepareAjax("onclick", handlers);
> }
> 
> prepareAjax() does a lookup to a new XML configuration file (well,
> in-memory objects representing the XML of course!) like so:
> 
> 
>   
> button1
> 
>   onClick
>   queryString
>   buttonValue=button1,textValue=text1
>   http://www.omnytex.com
>   stdInnerHTML
>   resultLayer
> 
>   
> 
> 
> If an  with an  matching the ajaxRef attribute is found,
> and if an  with a  matching the type being added to the tag
> is found, then the prepareAjax() method does its thing (note that
> developer-defined event handler functions will take precedent, so no
> existing code would be broken by this).  And what is "its thing" you ask?
> 
> Basically it will add an inline event handler to the tag, just like
> always, that is capable of making an Ajax request (using the
> XMLHttpRequest component).  A quick description of the XML elements
> pertaining to  should bring this in to focus:
> 
> type .. is of course the type of event handler.  It can be any of the
> types that the BaseHandlerTag handles.
> 
> submitType .. is the type of submission that will be made.  Two types are
> (will be) supported: queryString and XML.
> 
> submitItems .. is a comma-separated list of form elements and the names
> they should be given.  For instance, in the example above we would get a
> query string in the form ?buttonValue=<1>&textValue=<2> where <1> is the
> value of the button on the page and <2> is the value of the textbox on the
> page.
> 
> submitTarget .. is the URL the request is submitted to.  This can be a
> relative path or a full URL (although full URLs will of course incur the
> cross-site scripting restrictions)
> 
> returnAction .. is what will happen when the request returns.  There will
> be a number of built-in actions, all prefixed with "std' (let's get all
> the disease jokes out of the way now!).  You can also name a page-level
> Javascript function here to do other things.
> 
> returnTargets .. is a comma-separated list of elements on the page that
> will be affected by the action.  This will generally be required for the
> standard actions, and is up to the developer if they want it if writing
> their own function.
> 
> The code you hopefully downloaded is a sample webapp, very simple.  Click
> the button to retrieve the Struts web site and dump it in a span.  Note
> that if you are in an environment that requires a proxy for network
> access, you will need to set the httpProxy and httpPort elements in
> web.xml appropriately.  It is by default set up assuming no proxy is
> required.
> 
> The example has a number of quick-and-dirty type hacks just to
> demonstrate... for one, the XML config file is NOT read in, instead the
> objects are just populated manually in AjaxInit (which is a Struts p

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

ptooey...

I've always wanted to know how to spell that :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 18, 2005 10:29 am, Woodchuck said:
> eee... javascript...
>
> yuck, ptooey! ptooey!!
>
>
>
> --- "Vic Cekvenich (netsql)" <[EMAIL PROTECTED]> wrote:
>> Stéphane Zuckerman wrote:
>>   if this were to be integrated in Struts,
>> > my life would be easier.
>>
>> I too will now check it out.
>>
>> .V
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
> __
> Do you Yahoo!?
> Plan great trips with Yahoo! Travel: Now over 17,000 guides!
> http://travel.yahoo.com/p-travelguide
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Frank W. Zammetti]

On 4/6 I posted the following message to the Struts dev list... I can't
seem to find the thread in the list archives, if anyone else can I would
appreciate very much you posting the link to it...

This was discussing my proposal for integrating AJAX functionality into
the existing Struts taglibs.  There were some legitimate dissenting points
raised about this, and ultimately the idea was shot down.  However, I
still feel the idea has significant merit.

The proposal wasn't posted to the user list, and maybe I should have done
so... if there is support for this in the user community, I would be
willing to persue it further and provide it as part of the SF Struts
project.

P.S., I've added some notes here for some things that may not be as clear
as I would have liked, especially if you aren't terribly familiar with the
Struts code base, so if you see minor difference between this and what is
in the archives, that's all it is...



Subject: RFC: Struts HTML Ajax-Aware Tags

Afternoon all,

Please reference the code at:

http://www.omnytex.com/ajaxtags.zip

This is a complete webapp demonstrating the proposal (it isn't complete,
it is just to get the ideas across).

I wanted to put something out there in front of you all and get some
feedback on it before I go that extra mile and finish it out.

This came out of some ideas I tossed at Ted a few days ago.  The basic
idea is to take the existing Struts HTML taglib and make the tags
Ajax-aware.

In a nuthsell, take a simple button tag...



...now, add a new attribute to it, ajaxRef:



When the tag is rendered, each possible type of event handler (in the
BaseTagHandler class) looks something like this now:

if (getOnclick() != null) {
handlers.append(" onclick=\"");
handlers.append(getOnclick());
handlers.append("\"");
}
else {
  prepareAjax("onclick", handlers);
}

prepareAjax() does a lookup to a new XML configuration file (well,
in-memory objects representing the XML of course!) like so:


  
button1

  onClick
  queryString
  buttonValue=button1,textValue=text1
  http://www.omnytex.com
  stdInnerHTML
  resultLayer

  


If an  with an  matching the ajaxRef attribute is found,
and if an  with a  matching the type being added to the tag
is found, then the prepareAjax() method does its thing (note that
developer-defined event handler functions will take precedent, so no
existing code would be broken by this).  And what is "its thing" you ask?

Basically it will add an inline event handler to the tag, just like
always, that is capable of making an Ajax request (using the
XMLHttpRequest component).  A quick description of the XML elements
pertaining to  should bring this in to focus:

type .. is of course the type of event handler.  It can be any of the
types that the BaseHandlerTag handles.

submitType .. is the type of submission that will be made.  Two types are
(will be) supported: queryString and XML.

submitItems .. is a comma-separated list of form elements and the names
they should be given.  For instance, in the example above we would get a
query string in the form ?buttonValue=<1>&textValue=<2> where <1> is the
value of the button on the page and <2> is the value of the textbox on the
page.

submitTarget .. is the URL the request is submitted to.  This can be a
relative path or a full URL (although full URLs will of course incur the
cross-site scripting restrictions)

returnAction .. is what will happen when the request returns.  There will
be a number of built-in actions, all prefixed with "std' (let's get all
the disease jokes out of the way now!).  You can also name a page-level
Javascript function here to do other things.

returnTargets .. is a comma-separated list of elements on the page that
will be affected by the action.  This will generally be required for the
standard actions, and is up to the developer if they want it if writing
their own function.

The code you hopefully downloaded is a sample webapp, very simple.  Click
the button to retrieve the Struts web site and dump it in a span.  Note
that if you are in an environment that requires a proxy for network
access, you will need to set the httpProxy and httpPort elements in
web.xml appropriately.  It is by default set up assuming no proxy is
required.

The example has a number of quick-and-dirty type hacks just to
demonstrate... for one, the XML config file is NOT read in, instead the
objects are just populated manually in AjaxInit (which is a Struts plug-in
and is required to make the tags Ajax-aware).  Second, the query string is
currently not actually built, it's just hard-coded.  Third, only the
queryString submitType is recognized.  Fourth, only the stdInnerHTML
returnAction is recognized (as the name implies, this just sets the
innerHTML of any elements named in returnTargets).  And lastly, there is
very little commenting or proper error handling in spots.

Like I said, a very simple example, but I think it gets the p

Re: AJAX: Whoa, Nellie!

[Woodchuck]

eee... javascript...

yuck, ptooey! ptooey!!



--- "Vic Cekvenich (netsql)" <[EMAIL PROTECTED]> wrote:
> Stéphane Zuckerman wrote:
>   if this were to be integrated in Struts,
> > my life would be easier.
> 
> I too will now check it out.
> 
> .V
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 



__ 
Do you Yahoo!? 
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Vic Cekvenich (netsql)]

Stéphane Zuckerman wrote:
 if this were to be integrated in Struts,
my life would be easier.
I too will now check it out.
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Hubert Rabago]

For articles, blogs, libraries, etc, related to this technology, take
a look at http://www.ajaxmatters.com/

Our own Frank wrote an article about using it on
http://www.omnytex.com/articles/xhrstruts/

He also proposed integrating the technology with the Struts taglibs:
http://marc.theaimsgroup.com/?t=11128162732&r=3&w=2

Hubert


On 4/18/05, Rodolfo García Esteban/CYII <[EMAIL PROTECTED]> wrote:
> Where do we find information about this marvellous stuff?
> 
> Rodolfo __
> 
> Dakota Jack <[EMAIL PROTECTED]>
> 18/04/2005 15:02
> Por favor, responda a "Struts Users Mailing List"
> 
> Para:   Struts Users Mailing List 
> cc: (cco: Rodolfo García Esteban/CYII)
> Asunto: AJAX: Whoa, Nellie!
> 
> 
> I have been taking another look at the AJAX stuff that Frank Zammetti
> has provided.  This stuff is revolutionary.  Someone ought to be
> taking a close look at integrating such solutions, so far as it makes
> sense, into Struts.  This is not a passing fancy, in my estimation.
> This is a real solution to a persistent problem.  Further, this moves
> the solution to where the problem exists, on the client.  I, for one,
> am getting excited.  I am not saying to be precipitous, so the usual
> mundane warnings can be kept aside.  But, this is not the usual thing.
>  This is a fundamental shift in architecture that makes clear sense.
> 
> Jack
> 
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Dakota Jack]

Good overview, Stephane

On 4/18/05, Stéphane Zuckerman <[EMAIL PROTECTED]> wrote:
> Rodolfo García Esteban/CYII a écrit :
> > Where do we find information about this marvellous stuff?
> > 
> > Rodolfo __
> 
> Look for "XMLHttpRequest" and/or ActiveXObject("Microsoft.XMLHTTP")
> XML.com and the Apple dev center have good introductory articles about it.
> 
> Basically, this is a way to make server call from JavaScript via the
> XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer)
> objects. Thus it enables you to make dynamic calls to refresh some parts
> of a web page without reloading everything.
> 
> This is used with gmail for instance.
> 
> --
> Stéphane Zuckerman
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Dakota Jack]

http://wiki.apache.org/struts/AjaxStruts

On 4/18/05, Stéphane Zuckerman <[EMAIL PROTECTED]> wrote:
> Rodolfo García Esteban/CYII a écrit :
> > Where do we find information about this marvellous stuff?
> > 
> > Rodolfo __
> 
> Look for "XMLHttpRequest" and/or ActiveXObject("Microsoft.XMLHTTP")
> XML.com and the Apple dev center have good introductory articles about it.
> 
> Basically, this is a way to make server call from JavaScript via the
> XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer)
> objects. Thus it enables you to make dynamic calls to refresh some parts
> of a web page without reloading everything.
> 
> This is used with gmail for instance.
> 
> --
> Stéphane Zuckerman
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Dakota Jack]

http://wiki.apache.org/struts/AjaxStruts

On 4/18/05, Rodolfo García Esteban/CYII <[EMAIL PROTECTED]> wrote:
> Where do we find information about this marvellous stuff?
> 
> Rodolfo __
> 
> Dakota Jack <[EMAIL PROTECTED]>
> 18/04/2005 15:02
> Por favor, responda a "Struts Users Mailing List"
> 
> Para:   Struts Users Mailing List 
> cc: (cco: Rodolfo García Esteban/CYII)
> Asunto: AJAX: Whoa, Nellie!
> 
> 
> I have been taking another look at the AJAX stuff that Frank Zammetti
> has provided.  This stuff is revolutionary.  Someone ought to be
> taking a close look at integrating such solutions, so far as it makes
> sense, into Struts.  This is not a passing fancy, in my estimation.
> This is a real solution to a persistent problem.  Further, this moves
> the solution to where the problem exists, on the client.  I, for one,
> am getting excited.  I am not saying to be precipitous, so the usual
> mundane warnings can be kept aside.  But, this is not the usual thing.
>  This is a fundamental shift in architecture that makes clear sense.
> 
> Jack
> 
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Stéphane Zuckerman]

Rodolfo García Esteban/CYII a écrit :
Where do we find information about this marvellous stuff?

Rodolfo __
Look for "XMLHttpRequest" and/or ActiveXObject("Microsoft.XMLHTTP")
XML.com and the Apple dev center have good introductory articles about it.
Basically, this is a way to make server call from JavaScript via the 
XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer) 
objects. Thus it enables you to make dynamic calls to refresh some parts 
of a web page without reloading everything.

This is used with gmail for instance.
--
Stéphane Zuckerman
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Stéphane Zuckerman]

Dakota Jack a écrit :
 This is a fundamental shift in architecture that makes clear sense.
I tend to agree with you, and if this were to be integrated in Struts, 
my life would be easier (I am using AJAX stuff in some parts of my 
webapp). However, I have a serious concern related to security : this is 
still JavaScript :-)

--
Stéphane Zuckerman
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Actions and Action Mappings instantiated once?

[Joe Germuska]

At 6:48 AM -0400 4/18/05, Néstor Boscán wrote:
Hi
When I create a struts-config.xml that has many nodes that call the same
action class, is the action class instantietad once, or is instantiated for
every node?. What happens if I have a custom action mapping class, is
instantiated once or is instantiated for every node?.
Freddy pretty much answered you, but yes, by 
Struts original design, Action and ActionMapping 
classes are created once at Servlet 
initialization and are reused throughout.

Note that if you use the wildcard action-mapping 
functionality added in Struts 1.2, then 
necessarily a new ActionMapping is created for 
each request, because part of the functionality 
is to populate values of the mapping based on the 
details of the match.  (see 
http://struts.apache.org/userGuide/building_controller.html#action_mapping_wildcards) 

Several other MVC frameworks instantiate a 
controller (equivalent to a Struts Action) for 
each  request, and in fact, the Spring Framework 
provides (among other ways) a way of integrating 
with Struts which results in a new Action class 
being created for each request (see 
http://www.springframework.org/docs/reference/webintegration.html#struts)

If you didn't want to use Spring, it would still 
be relatively easy to extend the Struts 
RequestProcessor (or in Struts 1.3, extend or 
replace the CreateAction command) so that an 
Action was created for each request.

Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX: Whoa, Nellie!

[Rodolfo García Esteban/CYII]

Where do we find information about this marvellous stuff?

Rodolfo __




Dakota Jack <[EMAIL PROTECTED]>
18/04/2005 15:02
Por favor, responda a "Struts Users Mailing List"

 
Para:   Struts Users Mailing List 
cc: (cco: Rodolfo García Esteban/CYII)
Asunto: AJAX: Whoa, Nellie!


I have been taking another look at the AJAX stuff that Frank Zammetti
has provided.  This stuff is revolutionary.  Someone ought to be
taking a close look at integrating such solutions, so far as it makes
sense, into Struts.  This is not a passing fancy, in my estimation. 
This is a real solution to a persistent problem.  Further, this moves
the solution to where the problem exists, on the client.  I, for one,
am getting excited.  I am not saying to be precipitous, so the usual
mundane warnings can be kept aside.  But, this is not the usual thing.
 This is a fundamental shift in architecture that makes clear sense.

Jack


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AJAX: Whoa, Nellie!

[Dakota Jack]

I have been taking another look at the AJAX stuff that Frank Zammetti
has provided.  This stuff is revolutionary.  Someone ought to be
taking a close look at integrating such solutions, so far as it makes
sense, into Struts.  This is not a passing fancy, in my estimation. 
This is a real solution to a persistent problem.  Further, this moves
the solution to where the problem exists, on the client.  I, for one,
am getting excited.  I am not saying to be precipitous, so the usual
mundane warnings can be kept aside.  But, this is not the usual thing.
 This is a fundamental shift in architecture that makes clear sense.

Jack


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: User Certificates and application managed security -- possibl e??

[Tom Bednarz]

Hello Jesse,
Thanks for you input. I will try to get more info from the Tomcat 
userlist regarding which version supports what.
Tom

Jesse Alexander (KBSA 21) wrote:
Hi
With a newer Tomcat you might use a solution similar to what I have already seen
in a WebLogic-installation:
Several security-providers were created and configured. The first one
to able to authenticate the user does the job. Therefor the first would 
be an authenticator that can handle the chipcard-certificates, afterwards
you could define a standard handler that can handle a basic-authentication.
This can also be done only for the developer's workstation.

In your app you would then use just the J2EE-principal and roles.
I think it should be possible from TC5 on upward
hth
Alexander
-Original Message-
From: Tom Bednarz [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 11:44 AM
To: Struts Users Mailing List
Subject: User Certificates and application managed security -- possible??

Hi,
We have a customer who is introducing chip cards with 
client-certificates for single sign on. Because of this I have to change 
a web-application we provided. The application implements its own 
security mechanisms and uses roles (defined for every action in 
struts-config.xml) and roles in struts-menu to control access to offered 
functionalities.

If I understand things correctly, to support client-certificates  I need 
to define (beside SSL which is already supported)  in my web.xml 
something like:


   CLIENT-CERT

What happens to users who DO NOT have a certificate? In my program code 
I would be able to present a login-page and perform a different (second) 
method of authentication. If I understand things right, the above tag 
FORCES users to present a certificate to Tomcat (or whatever server) and 
fails otherwise.

How can this be solved? I should implement something like:
Is a certificate there? If yes read it and continue in the web app. If 
not, open a login screen and allow a username / password authentication. 
Once the authentication was successful I read the roles from a database 
server and everything should work as it does now (without client 
certificates)

Many thanks for your help
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Actions and Action Mappings instantiated once?

[Freddy Villalba A.]

Hello, Nestor.

I'm not sure what you mean exactly by "node". Anyway, according to Struts'
online doc:

"Write code for a multi-threaded environment - The controller servlet
creates only one instance of your Action class, and uses this one instance
to service all requests..."

Not sure if this is what you mean, though.

Cheers,
Freddy.

-Mensaje original-
De: Néstor Boscán [mailto:[EMAIL PROTECTED]
Enviado el: lunes, 18 de abril de 2005 12:49
Para: 'Struts Users Mailing List'
Asunto: Actions and Action Mappings instantiated once?


Hi

When I create a struts-config.xml that has many nodes that call the same
action class, is the action class instantietad once, or is instantiated for
every node?. What happens if I have a custom action mapping class, is
instantiated once or is instantiated for every node?.

Regards,

Néstor Boscán


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

java.lang.IllegalArgumentException calling an Action

[Rodolfo García Esteban/CYII]

Hi all,

I'm developing with struts 1.2.4, I have an action with form as beans, not 
dynamic, field in which I introduce data are String, and I have another 
field without values. When I do commit, then programs doesn't touch my 
action I obtain befere the next error:

javax.servlet.ServletException: BeanUtils.populate
 org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497)
 
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)
 
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
 org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
 org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

Root Cause:

java.lang.IllegalArgumentException: argument type mismatch
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 java.lang.reflect.Method.invoke(Method.java:324)
 
org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789)
 
org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684)
 
org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713)
 org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019)
 org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)
 org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495)
 
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)
 
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
 org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
 org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:802)


Could somebody help me?

Thanks


Rodolfo ___

Use of frames and security softwares in browser

[Antony Paul]

Hi all,
I plan to use frames for a site where in the user will feel that
he is one site while it will be pulling content from another site.
Here my question is will any kind of security software installed in a
browser will detect this and report to the user or prevent the content
from being displayed ?. Does any such software exists ?. Then what
will be the alternative ?.
-- 
rgds
Antony Paul
http://www.geocities.com/antonypaul24/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Actions and Action Mappings instantiated once?

[Néstor Boscán]

Hi

When I create a struts-config.xml that has many nodes that call the same
action class, is the action class instantietad once, or is instantiated for
every node?. What happens if I have a custom action mapping class, is
instantiated once or is instantiated for every node?.

Regards,

Néstor Boscán


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[OT] Steps for Configuring WAS 5.0 Websphere MQ

[Prasenjit Narwade]

The requirement is, I need a Message Driven Bean which will recieve messages
from Websphere MQ. 

I am finding problems doing the configuration in WSAD as well as in WAS. 

Any pointers to Configuring for MDB - MQ in (1) WSAD 5.1 and (2) WAS 5.0
will be really helpful.

Thanks in advance,

Prasenjit






"Quinnox is a SEI-CMM; ISO 9001:2000 accredited Global IT Services company
providing solutions in areas of E-Business, ERP, Application Management
Services and EAI to customers in BFSI, Manufacturing, Retail, Telecom and
Healthcare sector, powered by our Global Delivery Model."

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: User Certificates and application managed security -- possibl e??

[Jesse Alexander (KBSA 21)]

Hi

With a newer Tomcat you might use a solution similar to what I have already seen
in a WebLogic-installation:
Several security-providers were created and configured. The first one
to able to authenticate the user does the job. Therefor the first would 
be an authenticator that can handle the chipcard-certificates, afterwards
you could define a standard handler that can handle a basic-authentication.
This can also be done only for the developer's workstation.

In your app you would then use just the J2EE-principal and roles.

I think it should be possible from TC5 on upward

hth
Alexander

-Original Message-
From: Tom Bednarz [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 11:44 AM
To: Struts Users Mailing List
Subject: User Certificates and application managed security -- possible??

Hi,

We have a customer who is introducing chip cards with 
client-certificates for single sign on. Because of this I have to change 
a web-application we provided. The application implements its own 
security mechanisms and uses roles (defined for every action in 
struts-config.xml) and roles in struts-menu to control access to offered 
functionalities.

If I understand things correctly, to support client-certificates  I need 
to define (beside SSL which is already supported)  in my web.xml 
something like:


CLIENT-CERT


What happens to users who DO NOT have a certificate? In my program code 
I would be able to present a login-page and perform a different (second) 
method of authentication. If I understand things right, the above tag 
FORCES users to present a certificate to Tomcat (or whatever server) and 
fails otherwise.

How can this be solved? I should implement something like:

Is a certificate there? If yes read it and continue in the web app. If 
not, open a login screen and allow a username / password authentication. 
Once the authentication was successful I read the roles from a database 
server and everything should work as it does now (without client 
certificates)

Many thanks for your help

Tom


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

User Certificates and application managed security -- possible??

[Tom Bednarz]

Hi,
We have a customer who is introducing chip cards with 
client-certificates for single sign on. Because of this I have to change 
a web-application we provided. The application implements its own 
security mechanisms and uses roles (defined for every action in 
struts-config.xml) and roles in struts-menu to control access to offered 
functionalities.

If I understand things correctly, to support client-certificates  I need 
to define (beside SSL which is already supported)  in my web.xml 
something like:


   CLIENT-CERT

What happens to users who DO NOT have a certificate? In my program code 
I would be able to present a login-page and perform a different (second) 
method of authentication. If I understand things right, the above tag 
FORCES users to present a certificate to Tomcat (or whatever server) and 
fails otherwise.

How can this be solved? I should implement something like:
Is a certificate there? If yes read it and continue in the web app. If 
not, open a login screen and allow a username / password authentication. 
Once the authentication was successful I read the roles from a database 
server and everything should work as it does now (without client 
certificates)

Many thanks for your help
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Best practice for storing configuration data

[Jesse Alexander (KBSA 21)]

I prefer to have config-data either
- in the servers-settings (web.xml, jndi,...)
or
- in a separate file (usually xml-format)

In the second case at least the exact position of the config-file is
defined outside the war-file (either in the server jndi-tree or a 
system-property).

hth
Alexander

-Original Message-
From: Simone-dev [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 18, 2005 10:04 AM
To: Struts Users Mailing List
Subject: Re: Best practice for storing configuration data

Great,
I like the idea of storing data inside the server.xml or using the admin 
tool...
using the  tag... if you have access to the adminstration 
of the server

unfortunately this doesn't work if you just have access to you context 
directory...
 From what I read on all the thread
http://marc.theaimsgroup.com/?t=7687427&r=1&w=2 


the only possibile solution is saving application data in the web.xml

simone

Erik Weber wrote:

> Related:
>
> http://www.mail-archive.com/user@struts.apache.org/msg24083.html
>
>
> Erik
>
>
>
> Simone - Dev wrote:
>
>> Today I run into an dubt:
>> is the way I always used to store application dependent configuration 
>> is correct?
>>  
>> I use to store this kind of information in the we.xml file using 
>>  like this one
>>  
>>  
>>   uploadedFilePath
>>   
>> D:/Documenti/Progetti/jClubHouse/build/uploadedFiles/
>>  
>>
>>   The path to save the uploadedFiles to
>>  
>>  
>> and then inside actions, I retrieve it using
>>  
>> String 
>> uploadDir=getServlet().getServletContext().getInitParameter("uploadedFilePath");
>>  
>>
>>  
>>  
>> is there a better practice or is this the right one?
>>  
>> Simone
>>  
>> -
>> Simone Chiaretta
>> www.piyosailing.com/S 
>> /Any sufficiently advanced technology is indistinguishable from magic/
>> /"Life is short, play hard"/
>>
>> 
>>  
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]