Re: Ajax Theme

[Musachy Barroso]

On 2.1 ajax validation will be provided by Dojo by default, but other
libraries can be used easily, (with prototype example):

http://struts.apache.org/2.x/docs/ajax-validation.html

musachy

On 8/17/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> I haven't dived into this part of the source code, but I've beent
> taking "The ajax validation depends on DWR" to mean that we use DWR to
> call the usual server-side validators from client-side ajax code. Is
> that correct?
>
> Is the use of DWR changing from 2.0.x to 2.1.x?
>
> Does the YUI Ajax plugin support validation?
>
> Has anyone tried the YUI plugin against the head?
>
> (And just to make our question day complete:)
>
> Do we want to bundle the Dojo plugin with Struts 2.1.x, or do we want
> to consider moving it to a Google Code site (perhpas with YUI), while
> it is still "experimental":
>
> -Ted.
>
> On 8/15/07, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> > The ajax validation depends on DWR
> >
> > musachy
> >
> > On 8/15/07, Ian Roughley <[EMAIL PROTECTED]> wrote:
> > > Is the ajax theme in the 2.0.x branch completely Dojo driven now?  If
> > > so, there seems to be a lot of DWR code that could be removed (i.e. from
> > > the web.xml and form.ftl).  I can open a ticket if this is the case.
> > >
> > > /Ian
> > >
> > > -
> > > 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]
> >
> >
>
>
> --
> HTH, Ted 
>
> -
> 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]

Re: Ajax Theme

[Ted Husted]

I haven't dived into this part of the source code, but I've beent
taking "The ajax validation depends on DWR" to mean that we use DWR to
call the usual server-side validators from client-side ajax code. Is
that correct?

Is the use of DWR changing from 2.0.x to 2.1.x?

Does the YUI Ajax plugin support validation?

Has anyone tried the YUI plugin against the head?

(And just to make our question day complete:)

Do we want to bundle the Dojo plugin with Struts 2.1.x, or do we want
to consider moving it to a Google Code site (perhpas with YUI), while
it is still "experimental":

-Ted.

On 8/15/07, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> The ajax validation depends on DWR
>
> musachy
>
> On 8/15/07, Ian Roughley <[EMAIL PROTECTED]> wrote:
> > Is the ajax theme in the 2.0.x branch completely Dojo driven now?  If
> > so, there seems to be a lot of DWR code that could be removed (i.e. from
> > the web.xml and form.ftl).  I can open a ticket if this is the case.
> >
> > /Ian
> >
> > -
> > 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]
>
>


-- 
HTH, Ted 

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

Re: [S2] Proposal: Povide an integrated reference link feature for UI tags

[Ted Husted]

If I understand the use case, in my own applications, we done things
like add a separate button to the page to do things like edit or add a
company. (Are we distinguishing between insert and update?) It is a
common UI need.

In the case of select controls, some applications handle this sort of
thing with a meta-item, like "add new item" that is part of the list.
I can remember elder versions of Quicken doing this, though I note
later versions have moved to buttons and menu bar items for adding or
editing items.

I can see how adding the feature to the template might be useful.
Though, in the case of editing items in an enterprise application, the
notion of user roles can come into play. Some users might be
authorized to add items, and others might not.

-Ted.

On 8/17/07, Rene Gielen <[EMAIL PROTECTED]> wrote:
> In many (but not only) CRUD applications you have to deal with referencing
> model objects, which have an associated view as well. For example, if you
> have an editContact view, you have a "company" select box in place
> referencing the company model entity, which has it's own editCompany view.
>
> A IMO common pattern in this case is to provide a direct link to the view
> for the referenced model object. For example, you could provide a small
> link symbol behind the select box, representing an  to the
> view for the referenced entity object.
>
> Another common usecase could be to provide a complex selection popup with
> sorting / filtering, if a simple select box would not be suitable. This
> could happen with a not editable textbox, being filled from the popup
> window you access from the link symbol beside the textbox.
>
> Due to the structure of out templates, it might get quite complicated to
> render such a link symbol outside the tag. If you use a table based
> template for example, you would want to render the symbol within the 
> encapsulating the  element.
>
> I would propose the following extension to our UI tags:
> 1. provide a referenceLink attribute
> 2. provide a referenceSymbol attribute
> 3. provide a referenceText attribute
>
> The rendering of a reference link would be triggered by the existence of a
> referenceLink attribute. The refernceSymbol attribute could have a common
> default pointing to a provided image, similar to tooltip. You could
> optionally provide another symbol or the keyword "none" if you dont like
> to have an image rendered.
> If the referenceText attribute is given, it render as the alt tag of the
> image, if not symbol attribute is set to none. In this case, it would be
> the text presented by an alternatively rendered .
> Our themes would provide a default view implementation of this feature,
> leaving it open to users to easily customize it their own need with simple
> template editing, since the needed attributes are provided in the tag
> model.
>
> Comments highly appreciated.
>
> Regards,
> Rene

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

DO NOT REPLY [Bug 20854] - Error with nesting tags in separate pages

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=20854





--- Additional Comments From [EMAIL PROTECTED]  2007-08-17 09:04 ---
I think I have just hit the same problem i.e. "cannot find bean with name "" in
any scope" when using two s in the same tile.  I am using struts
1.3.5

In which version has this bug been fixed?  Is there a patch or workaround I can
apply?

I see in JIRA that a similar bug STR-1530 has just been reopened so i was
wondering what the status was

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Exception thrown in OGNL evaluation.

[Rene Gielen]

Am Fr, 17.08.2007, 11:28, schrieb Ruimo Uno:
> Rane,
>
> 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>:
>> Ruimo,
>>
>> see below
>>
>> Ruimo Uno schrieb:
>> > Hi, thanks for your comment.
>> >
>> > 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>:
>> >> It's no bug, it's a feature...
>> >>
>> >> The policy for model access (e.g. property calls) via expression
>> >> evaluation is fail silent. It would cause tons of exceptions if ognl
>> >> expression evaluation / property access would not swallow them.
>> >
>> > I feel it is overkill. The property getters in action classes may
>> > throw RuntimeException because of programming bugs. Even in this case,
>> > the current implementation just ignore the exception and the shown
>> > page will be just corrupted. We cannot show user friendly 'sorry page'
>> > because the Struts exception handler cannot get exception.
>> >
>>
>> You would not be able to use the most common use patterns without having
>> to do exepction handling on the JSP page then! Think of a model object
>> foo with a getter getFoo() in your a FooCrudAction. You have an
>> editFoo.jsp. If you want to create a new foo entry, the sequence would
>> be
>> - invoke edit/create action, triggering execute() in FooCrudAction
>> - render editFoo.jsp
>> - submit form
>> - invoke save action, triggering save() in FooCrudAction
>> - on success, render editFoo.jsp
>>
>> if ognl would not swallow the exceptions, then placing simple tag like
>> 
>> would fail with NPE in first rendering if you did not provide a
>> (unnecessary) this.foo=new Foo() in your execute() method, or a lazy
>> getter. Just a simple example. But if you would change this behaviour,
>> the showcase app code would need approximately an additional 10-15% more
>> code just for doing unneeded initializations and exception handling.
>
> You won't get NPE in this scenario. Ognl automatically create instance
> for you. I believe you know about this feature.
>

Not when trying to read the property, only when applying values. The first
invocation with null foo object will cause OGNL to try to read the
property of the foo.name property and fail silently - no object will be
created. This will happen when then parameters interceptor tries to apply
values to the model (when invoking the save view)

>> What if the execption is thrown? It will be thrown within JSP page
>> handling, and swallowed there! Your OpenSessionInView Interceptor or any
>> higher level layer would take no notice of the exception. Instead you
>> would have to use the anti-pattern of exception handliing with in JSP
>> code to present useful information.
>
> In the API specification for PageContext.handleException() states the
> following:
>
> ---
> If no error page is defined in the page, the exception should be
> rethrown so that the standard servlet error handling takes over.
> ---
>
> If my understanding is correct, the exception should be rethrown and
> the servlet layer can handle it.
>

good point, my fault. But nevertheless, your controller should be
responsible for deciding what to present, and where to dispatch to. This
is commonly done with either having your action method return results
other than "success" (eg. "error" then) or having your interceptor change
the result after dealing with the exception.

>> >> Most likely, you are doing business logic calls in your model access
>> >> domain and you should think of moving any call with the possibility
>> to get
>> >> service relevant exceptions to the described business logic domain
>> access
>> >> methods.
>> >
>> > No, it is not 'business logc'. In 'open session in view' pattern, the
>> > db transaction is kept open until the view rendering finishies. If you
>> > call the property access method of the acction class, it calls the
>> > getter method of tne entity class. It triggers O/R mapping layer
>> > invocation and lazily accesses the database. As a result, some kind of
>> > system exception (such as SQLException) may be thrown while view
>> > rendering.
>> >
>>
>> This pattern is widely used, I'm using it myself in many applications.
>> But where do you expect the exception? If you make sure that you have a
>> foo object loaded from persistence layer, the the foo.getBars() call to
>> a a lazy initialized collection of referenced objects should never fail
>> due to _runtime_ problems you have to deal with. If, for example, for
>> some reason your session is closed, you have to look for a design time
>> problem - most commonly people forget about holding the session open
>> (luckily we have OpenSessionInView).
>
> Closing the session should be fixed as a design bug. I agree with you
> at this point. But in this case, the system should show an user
> friendly 'sorry page' so that the user can perform appropriate action.
> As we cannot take all bugs out of our system, need a sfety net. If
> there is a network problem between ap server and db server, lazy
> loading will fail by system error.
>

but how could the fooService.getById(

Re: Exception thrown in OGNL evaluation.

[Ruimo Uno]

Rane,

2007/8/17, Rene Gielen <[EMAIL PROTECTED]>:
> Ruimo,
>
> see below
>
> Ruimo Uno schrieb:
> > Hi, thanks for your comment.
> >
> > 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>:
> >> It's no bug, it's a feature...
> >>
> >> The policy for model access (e.g. property calls) via expression
> >> evaluation is fail silent. It would cause tons of exceptions if ognl
> >> expression evaluation / property access would not swallow them.
> >
> > I feel it is overkill. The property getters in action classes may
> > throw RuntimeException because of programming bugs. Even in this case,
> > the current implementation just ignore the exception and the shown
> > page will be just corrupted. We cannot show user friendly 'sorry page'
> > because the Struts exception handler cannot get exception.
> >
>
> You would not be able to use the most common use patterns without having
> to do exepction handling on the JSP page then! Think of a model object
> foo with a getter getFoo() in your a FooCrudAction. You have an
> editFoo.jsp. If you want to create a new foo entry, the sequence would be
> - invoke edit/create action, triggering execute() in FooCrudAction
> - render editFoo.jsp
> - submit form
> - invoke save action, triggering save() in FooCrudAction
> - on success, render editFoo.jsp
>
> if ognl would not swallow the exceptions, then placing simple tag like
> 
> would fail with NPE in first rendering if you did not provide a
> (unnecessary) this.foo=new Foo() in your execute() method, or a lazy
> getter. Just a simple example. But if you would change this behaviour,
> the showcase app code would need approximately an additional 10-15% more
> code just for doing unneeded initializations and exception handling.

You won't get NPE in this scenario. Ognl automatically create instance
for you. I believe you know about this feature.

> What if the execption is thrown? It will be thrown within JSP page
> handling, and swallowed there! Your OpenSessionInView Interceptor or any
> higher level layer would take no notice of the exception. Instead you
> would have to use the anti-pattern of exception handliing with in JSP
> code to present useful information.

In the API specification for PageContext.handleException() states the following:

---
If no error page is defined in the page, the exception should be
rethrown so that the standard servlet error handling takes over.
---

If my understanding is correct, the exception should be rethrown and
the servlet layer can handle it.

> >> Most likely, you are doing business logic calls in your model access
> >> domain and you should think of moving any call with the possibility to get
> >> service relevant exceptions to the described business logic domain access
> >> methods.
> >
> > No, it is not 'business logc'. In 'open session in view' pattern, the
> > db transaction is kept open until the view rendering finishies. If you
> > call the property access method of the acction class, it calls the
> > getter method of tne entity class. It triggers O/R mapping layer
> > invocation and lazily accesses the database. As a result, some kind of
> > system exception (such as SQLException) may be thrown while view
> > rendering.
> >
>
> This pattern is widely used, I'm using it myself in many applications.
> But where do you expect the exception? If you make sure that you have a
> foo object loaded from persistence layer, the the foo.getBars() call to
> a a lazy initialized collection of referenced objects should never fail
> due to _runtime_ problems you have to deal with. If, for example, for
> some reason your session is closed, you have to look for a design time
> problem - most commonly people forget about holding the session open
> (luckily we have OpenSessionInView).

Closing the session should be fixed as a design bug. I agree with you
at this point. But in this case, the system should show an user
friendly 'sorry page' so that the user can perform appropriate action.
As we cannot take all bugs out of our system, need a sfety net. If
there is a network problem between ap server and db server, lazy
loading will fail by system error.

> The best practice pattern for a displaying a foo object looks like this:
>
> - invoke showFoo.action?id=1
> - prepare() method of your action: this.foo = fooService.getById(this.id)
> - handle any exception you like, or let it pop to the upper layers
> - on success, render showFoo.jsp
> - iterate over foo.bars in view - will be lazy initialized, but should
> not throw any exception is your design was proper

My previous example may be poor to explain this issue. Sorry for that.
But as I stated above, you still need to care about system exception
and RuntimeException (thrown by programming bug). I am not talking
about application exception. You can hardly avoid system error and
programming bug by implementing logics in your code.

> but if there was an exception, and OGNL would pop it, you still would
> _never_ get it in your Interceptor - your container will

[S2] Proposal: Povide an integrated reference link feature for UI tags

[Rene Gielen]

In many (but not only) CRUD applications you have to deal with referencing
model objects, which have an associated view as well. For example, if you
have an editContact view, you have a "company" select box in place
referencing the company model entity, which has it's own editCompany view.

A IMO common pattern in this case is to provide a direct link to the view
for the referenced model object. For example, you could provide a small
link symbol behind the select box, representing an  to the
view for the referenced entity object.

Another common usecase could be to provide a complex selection popup with
sorting / filtering, if a simple select box would not be suitable. This
could happen with a not editable textbox, being filled from the popup
window you access from the link symbol beside the textbox.

Due to the structure of out templates, it might get quite complicated to
render such a link symbol outside the tag. If you use a table based
template for example, you would want to render the symbol within the 
encapsulating the  element.

I would propose the following extension to our UI tags:
1. provide a referenceLink attribute
2. provide a referenceSymbol attribute
3. provide a referenceText attribute

The rendering of a reference link would be triggered by the existence of a
referenceLink attribute. The refernceSymbol attribute could have a common
default pointing to a provided image, similar to tooltip. You could
optionally provide another symbol or the keyword "none" if you dont like
to have an image rendered.
If the referenceText attribute is given, it render as the alt tag of the
image, if not symbol attribute is set to none. In this case, it would be
the text presented by an alternatively rendered .
Our themes would provide a default view implementation of this feature,
leaving it open to users to easily customize it their own need with simple
template editing, since the needed attributes are provided in the tag
model.

Comments highly appreciated.

Regards,
Rene


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

Re: Exception thrown in OGNL evaluation.

[Rene Gielen]

Ruimo,

see below

Ruimo Uno schrieb:

Hi, thanks for your comment.

2007/8/17, Rene Gielen <[EMAIL PROTECTED]>:

It's no bug, it's a feature...

The policy for model access (e.g. property calls) via expression
evaluation is fail silent. It would cause tons of exceptions if ognl
expression evaluation / property access would not swallow them.


I feel it is overkill. The property getters in action classes may
throw RuntimeException because of programming bugs. Even in this case,
the current implementation just ignore the exception and the shown
page will be just corrupted. We cannot show user friendly 'sorry page'
because the Struts exception handler cannot get exception.



You would not be able to use the most common use patterns without having 
to do exepction handling on the JSP page then! Think of a model object 
foo with a getter getFoo() in your a FooCrudAction. You have an 
editFoo.jsp. If you want to create a new foo entry, the sequence would be

- invoke edit/create action, triggering execute() in FooCrudAction
- render editFoo.jsp
- submit form
- invoke save action, triggering save() in FooCrudAction
- on success, render editFoo.jsp

if ognl would not swallow the exceptions, then placing simple tag like

would fail with NPE in first rendering if you did not provide a 
(unnecessary) this.foo=new Foo() in your execute() method, or a lazy 
getter. Just a simple example. But if you would change this behaviour, 
the showcase app code would need approximately an additional 10-15% more 
code just for doing unneeded initializations and exception handling.


What if the execption is thrown? It will be thrown within JSP page 
handling, and swallowed there! Your OpenSessionInView Interceptor or any 
higher level layer would take no notice of the exception. Instead you 
would have to use the anti-pattern of exception handliing with in JSP 
code to present useful information.



Most likely, you are doing business logic calls in your model access
domain and you should think of moving any call with the possibility to get
service relevant exceptions to the described business logic domain access
methods.


No, it is not 'business logc'. In 'open session in view' pattern, the
db transaction is kept open until the view rendering finishies. If you
call the property access method of the acction class, it calls the
getter method of tne entity class. It triggers O/R mapping layer
invocation and lazily accesses the database. As a result, some kind of
system exception (such as SQLException) may be thrown while view
rendering.



This pattern is widely used, I'm using it myself in many applications. 
But where do you expect the exception? If you make sure that you have a 
foo object loaded from persistence layer, the the foo.getBars() call to 
a a lazy initialized collection of referenced objects should never fail 
due to _runtime_ problems you have to deal with. If, for example, for 
some reason your session is closed, you have to look for a design time 
problem - most commonly people forget about holding the session open 
(luckily we have OpenSessionInView).

The best practice pattern for a displaying a foo object looks like this:

- invoke showFoo.action?id=1
- prepare() method of your action: this.foo = fooService.getById(this.id)
- handle any exception you like, or let it pop to the upper layers
- on success, render showFoo.jsp
- iterate over foo.bars in view - will be lazy initialized, but should 
not throw any exception is your design was proper


but if there was an exception, and OGNL would pop it, you still would 
_never_ get it in your Interceptor - your container will swallow it when 
rendering the JSP.


it's the same for saving etc as well.

Did you check out these?:
http://cwiki.apache.org/confluence/display/WW/CRUD+Demo+I
http://appfuse.org/display/APF/Demos+and+Videos

Regards,
Rene


Am Do, 16.08.2007, 17:01, schrieb Ruimo Uno:

Hi,

I have submitted this to user list a few hours ago but finally, I
found the root cause of this issue. So, here I report it to dev list.
If an exception is thrown while OGNL expression evaluation such as in
the following scenario:

XXXAction
public String getMessage() {
throw new NullPointerException();
}

XXX.jsp
  

The exception is wrapped in an OgnlException and re-thrown.  It is
caught in com.opensymphony.xwork2.util.CompoundRootAccessor.getProperty()
and wrapped in a XWorkException() and re-thrown.

} catch (OgnlException e) {
if (e.getReason() != null) {
final String msg = "Caught an Ognl exception while getting
property " + name;
throw new XWorkException(msg, e);
}
} catch (IntrospectionException e) {

Finally, it is caught in
com.opensymphony.xwork2.util.OgnlValueStack.findValue(String, Class)
and swallowed.

} catch (Exception e) {
logLookupFailure(expr, e);

return findInContext(expr);
} finally {

As a result, the upper layer does not receive any exception. So