Re: dojo version in struts 2.0.11?

2007-11-11 Thread Ted Husted 
Please keep in mind that the "Ajax-as-Theme" approach taken in Struts
2.0.x has been tagged "end of life" by the development group. In
Struts 2.1.x, the Ajax JSP tags are being expressed as a plugin.

We do welcome everyone's help, but the best place to put a significant
amount of effort would be the Struts 2.1.x Dojo plugin. Otherwise, we
are going to end up with two representations of the code.

-Ted.

On Nov 10, 2007 1:04 PM, Alvaro Sanchez-Mariscal
<[EMAIL PROTECTED]> wrote:
> We currently use 2.0.8, but we are willing to move to 2.0.11 if we can
> use Dojo 1.0.
>
>
> On Nov 10, 2007 11:05 AM, Sami Dalouche <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > it would be awesome to build a production-quality version on top of what
> > I started.
> >
> > as Antonio suggested, I created a JIRA feature request for that :
> > https://issues.apache.org/struts/browse/WW-2311 and attached the theme
> > here.
> >
> > The code is currently built against struts 2.0.11, which is the version
> > I currently use.
> > Alvaro- Which version are you targetting ?
> >
> > Regards,
> > Sami Dalouche
> >
> > Le vendredi 09 novembre 2007 à 12:25 +0100, Alvaro Sanchez-Mariscal a
> > écrit :
> >
> > > Hi Sami,
> > >
> > > My company (Salenda) is willing to contribute to get a
> > > production-quality version.
> > >
> > > Perhaps sharing source code in a cvs/subversion may be a good starting 
> > > point.
> > >
> > > Anybody else interested?
> > >
> > > Alvaro.
> > >
> > > On Nov 9, 2007 12:09 PM, Sami Dalouche <[EMAIL PROTECTED]> wrote:
> > > > If anyone is interested, I have created my own dojo 1.0.0 theme for
> > > > standard Struts 2 tags. (works on Dojo 2.0.11).
> > > >
> > > > It's far from being *clean*, far from being complete, uses undocumented
> > > > attributes, but is a good starting guide to create progressive
> > > > JavaScript enhancement (falls back to pure HTML widgets if JS is not
> > > > enabled).
> > > >
> > > > So, do not hesitate to drop me an email if you want to look at the code,
> > > > or plan to cleanly repackage it for Struts, it's available under
> > > > whatever open source license you prefer.
> > > >
> > > > Regards,
> > > > Sami Dalouche
> > > >
> > > >
> > > >
> > > > On Fri, 2007-11-09 at 21:25 +1100, Jeromy Evans wrote:
> > > > > Does anyone know -exactly- which revision of dojo is bundled in Struts
> > > > > 2.0.11?
> > > > >
> > > > > A diff of the src dirs reveals it's not the tagged 0.4.2 release or
> > > > > tagged 0.4.3 release.  I believe it's near 0.4.2 but can't find a 
> > > > > match.
> > > > >
> > > > > The dojo plugin in Struts 2.1.x definitely uses the 0.4.3 tagged 
> > > > > release.
> > > > >
> > > > > Max Pimm wrote
> > > > >  > Which is the dojo version that was used in the build of
> > > > > struts2-core-0.011.jar?
> > > > >
> > > > > -
> > > > > 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]
> >
> >
>
>
>
> --
> Alvaro Sanchez-Mariscal Arnaiz
> Java EE Architect & Instructor
> [EMAIL PROTECTED]
>
> -
>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
HTH, Ted 

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

Re: dojo version in struts 2.0.11?

2007-11-11 Thread Dave Newton 
Maybe it will run, but it won't compile--there's some
XWork logging (xwork2.util.logging.Logger &
LoggerFactory) and an annotation
(@StrutsTagSkipInheritance) in the plugin that aren't
in S2.0/XW<2.1.

d.
 
--- Musachy Barroso <[EMAIL PROTECTED]> wrote:

> The plugin code itself can be just copied to 2.0 and
> it should work.
> The rest would be deleting everything related to
> dojo from core.
> 
> musachy
> 
> On Nov 11, 2007 1:20 AM, Dave Newton
> <[EMAIL PROTECTED]> wrote:
> > --- Ted Husted <[EMAIL PROTECTED]> wrote:
> > > I wonder if it would be possible to retrofit the
> 2.1
> > > Dojo plugin for 2.0?
> >
> > I haven't started looking in to this in any depth
> (and
> > my initial naïve test didn't work) but aside from
> the
> > hard-coded theme name that has to be changed to
> not
> > conflict w/ the bundled templates and some XWork
> > 2.1/S2.1 stuff it shouldn't be a *huge* effort,
> but
> > Musachy's obviously the guy to ask about this.
> >
> > d.
> >
> >
> >
> >
>
-
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
> 
> 
> 
> -- 
> "Hey you! Would you help me to carry the stone?"
> Pink Floyd
> 
>
-
> 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]

Is directly setting the Action's fieldErrors map OK?

2007-11-11 Thread Gary Affonso 

I've got two questions, here's the summary:

I'm doing validation in my domain objects.  They kick back a map..

  public class DomainObject {
   public Map validate() {...}
  }

In my action's validate method, I just delegate to the domain object's 
validate() method.  Something like this...


  public void validate() {
// Delegate validation
Map errs = new LinkedHashMap();
errs.putAll(account.validate());
errs.putAll(postalAddress.validate());

setFieldErrors(errs);
  }

Here's my question...

As you can see from the above, when I get my errs Map back from my 
domain object (it will always be non-null) I've just been replacing the 
Action's field error map with my own...


  setFieldErrors(errs);

It's working now but it seems like blasting the existing Action's 
internal fieldErrors map with my own seems to be asking for trouble.


This option is compelling...

  public void validate() {
getFieldErrors().putAll(account.validate())
getFieldErrors().putAll(postalAddress.validate())
  }


But I have two problems with that.  It assumes the internal fieldErrors 
map will never be null (is that true?) and it also emits a warning (in 
Eclipse) because the the internal FieldErrors map has not be genericized 
(and my domain objects Map has).  I could code around both of those, of 
course, but then it's verbose enough to be not so compelling anymore.


Another option is to loop over error map generated by my domain object 
and then add each of those to the Action's FieldError map via 
addFieldError().  That seems the safest, presumably the addFieldError 
method is doing null checks, new map setup if necessary, etc.  But, 
dang, that's  a lot of code just to transfer some strings around.


Comments?

- Gary

P.S.  My Action is extending ActionSupport, this is how I'm ensuring 
that the Acition knows about things like FieldErrors.


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

Re: Is directly setting the Action's fieldErrors map OK?

2007-11-11 Thread Gary Affonso 
I just checked the source for ActionSupport's addFieldError (which 
delegates to ValidationAwareSupport's addFieldError).


It does do a null check on the internal FieldErrors and will initialize 
the map before adding a fieldError, if necessary.  So, yes, the internal 
FieldErrors map can be null.


But!...

getFieldErrors() also does a null check and will initialize the internal 
FieldErrors map if necessary (it won't return null).  So this should be 
fine (no null check required):


  getFieldErrors().putAll(account.validate())

I'm thinking this is preferable to just nuking the internal by replacing 
it with my own.


Now, if only the internal FieldErrors map was genericised.  One of two 
isn't bad, though. :-)


- Gary

Gary Affonso wrote:

I've got two questions, here's the summary:

I'm doing validation in my domain objects.  They kick back a map..

  public class DomainObject {
   public Map validate() {...}
  }

In my action's validate method, I just delegate to the domain object's 
validate() method.  Something like this...


  public void validate() {
// Delegate validation
Map errs = new LinkedHashMap();
errs.putAll(account.validate());
errs.putAll(postalAddress.validate());

setFieldErrors(errs);
  }

Here's my question...

As you can see from the above, when I get my errs Map back from my 
domain object (it will always be non-null) I've just been replacing the 
Action's field error map with my own...


  setFieldErrors(errs);

It's working now but it seems like blasting the existing Action's 
internal fieldErrors map with my own seems to be asking for trouble.


This option is compelling...

  public void validate() {
getFieldErrors().putAll(account.validate())
getFieldErrors().putAll(postalAddress.validate())
  }


But I have two problems with that.  It assumes the internal fieldErrors 
map will never be null (is that true?) and it also emits a warning (in 
Eclipse) because the the internal FieldErrors map has not be genericized 
(and my domain objects Map has).  I could code around both of those, of 
course, but then it's verbose enough to be not so compelling anymore.


Another option is to loop over error map generated by my domain object 
and then add each of those to the Action's FieldError map via 
addFieldError().  That seems the safest, presumably the addFieldError 
method is doing null checks, new map setup if necessary, etc.  But, 
dang, that's  a lot of code just to transfer some strings around.


Comments?

- Gary

P.S.  My Action is extending ActionSupport, this is how I'm ensuring 
that the Acition knows about things like FieldErrors.


-
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: Is directly setting the Action's fieldErrors map OK?

2007-11-11 Thread Ted Husted 
Submit a patch :)

On Nov 11, 2007 1:14 PM, Gary Affonso <[EMAIL PROTECTED]> wrote:
> Now, if only the internal FieldErrors map was genericised.  One of two
> isn't bad, though. :-)

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

[s2] LabelValueBean

2007-11-11 Thread Ted Husted 
Is there a corollary to the Struts 1 LabelValueBean in Struts 2?

 * 
http://svn.apache.org/viewvc/struts/struts1/trunk/core/src/main/java/org/apache/struts/util/LabelValueBean.java

-Ted.

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

Re: [s2] LabelValueBean

2007-11-11 Thread Tom Schneider 

Ted,
I think in webwork, were you only needed name value pairs, you would
typically use a Map.  All tags have built-in support for dealing with maps. 
Is there a specific use case that you've encountered where you needed that?
Tom


Ted Husted wrote:
> 
> Is there a corollary to the Struts 1 LabelValueBean in Struts 2?
> 
>  *
> http://svn.apache.org/viewvc/struts/struts1/trunk/core/src/main/java/org/apache/struts/util/LabelValueBean.java
> 
> -Ted.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-s2--LabelValueBean-tf4787015.html#a13696029
Sent from the Struts - User mailing list archive at Nabble.com.


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

Re: [s2] LabelValueBean

2007-11-11 Thread Ted Husted 
Quite right. A map works just fine. (Wish I could say the same for
some other platforms I know!)

On Nov 11, 2007 4:19 PM, Tom Schneider <[EMAIL PROTECTED]> wrote:
>
> Ted,
> I think in webwork, were you only needed name value pairs, you would
> typically use a Map.  All tags have built-in support for dealing with maps.
> Is there a specific use case that you've encountered where you needed that?
> Tom
>
>
>
> Ted Husted wrote:
> >
> > Is there a corollary to the Struts 1 LabelValueBean in Struts 2?
> >
> >  *
> > http://svn.apache.org/viewvc/struts/struts1/trunk/core/src/main/java/org/apache/struts/util/LabelValueBean.java
> >
> > -Ted.

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

[Tile2] Help in Page Layout

2007-11-11 Thread Raghuveer Rawat 
Hi, I have newbie in GUI design (Tiles/Menuing) etc. I need some urgent help
in Page Layout Design using Tile2/Struts Menu.
I am using below template for my page. Menu is very simple one so I have
just anchor tags in Header.jsp
















Now my other pages are extending this tile layout like below.








Left.jsp contains a number of link. When user click on these links content
of Center.jsp will also change.

Now again Center.jsp have 4-5 menu items and page will change besed on menu
item selection.
I am wondering what will be best way to Design Layout of this Center.jsp.

Anyone who can help me.

Re: [Tile2] Help in Page Layout

2007-11-11 Thread Antonio Petrelli 
Please ask this question to the Tiles Users mailing list:
http://tiles.apache.org/mail.html

Antonio

2007/11/12, Raghuveer Rawat <[EMAIL PROTECTED]>:
> Hi, I have newbie in GUI design (Tiles/Menuing) etc. I need some urgent help
> in Page Layout Design using Tile2/Struts Menu.
> I am using below template for my page. Menu is very simple one so I have
> just anchor tags in Header.jsp
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
> Now my other pages are extending this tile layout like below.
>
> 
> 
> 
> 
> 
> 
>
> Left.jsp contains a number of link. When user click on these links content
> of Center.jsp will also change.
>
> Now again Center.jsp have 4-5 menu items and page will change besed on menu
> item selection.
> I am wondering what will be best way to Design Layout of this Center.jsp.
>
> Anyone who can help me.
>

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