DO NOT REPLY [Bug 35703] New: - TilesUtilImpl doInclude() should call TilesRequestProcessor doInclude()... but it doesn't

2005-07-12 Thread 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=35703

   Summary: TilesUtilImpl doInclude() should call
TilesRequestProcessor doInclude()... but it doesn't
   Product: Struts
   Version: 1.2.7
  Platform: All
OS/Version: All
Status: NEW
  Severity: major
  Priority: P2
 Component: Tiles framework
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


TilesUtilImpl doInclude() methods do not call the TilesRequestProcessor but
instead use either pageContext or servletContext include() methods.
IMHO this is wrong.
That would definitely make sense to call the application's TilesRequestProcessor
as any Web App could implement its own (RequestProcessor) - as a subclass of
TilesRequestProcessor - which could basically override doInclude() and
doForward() or general request processing (action, JSP,... etc.).

IMO not calling the TilesRequestProcessor from TilesUtilsImpl fails part of the
contract of the RequestProcessor.
That's a major issue as far as I'm concerned.

Following is the patch I'm currently using to fix it (fix for 2 classes):
- First part of the patch is for TilesRequestProcessor to override
RequestProcessor doInclude() method to allow for calling overloaded methods of
subclasses of TilesRequestProcessor.
- Second part is the actual fix for TilesUtilImpl to call TilesRequestProcessor
doInclude() method.

===
TilesRequestProcessor
===

--- org/apache/struts/tiles/TilesRequestProcessor.java.orig 2005-05-06
10:48:22.0 +0200
+++ org/apache/struts/tiles/TilesRequestProcessor.java  2005-07-12
10:41:49.429375000 +0200
@@ -264,6 +264,25 @@
}
}
 
+/**
+ * Do an include using request dispatcher.
+ * Uri is a valid uri. 
+ * Necessary to allow usage of overloaded RequestProcessor.
+ * N.B.: scope is to make this method available to tiles package.
+ * @param uri Uri or Definition name to include.
+ * @param request Current page request.
+ * @param response Current page response.
+ */
+protected void doInclude(
+String uri,
+HttpServletRequest request,
+HttpServletResponse response)
+throws IOException, ServletException {
+  
+super.doInclude(uri, request, response);
+}
+
+
/**
 * Overloaded method from Struts' RequestProcessor.
 * Forward or redirect to the specified destination by the specified


===
TilesUtilImpl
===

--- org/apache/struts/tiles/TilesUtilImpl.java.orig 2005-05-06
10:48:16.0 +0200
+++ org/apache/struts/tiles/TilesUtilImpl.java  2005-07-12 14:28:23.148125000 
+0200
@@ -30,6 +30,7 @@
 
 import org.apache.commons.logging.Log;
 import org.apache.commons.logging.LogFactory;
+import org.apache.struts.Globals;
 import org.apache.struts.tiles.definition.ComponentDefinitionsFactoryWrapper;
 import org.apache.struts.util.RequestUtils;
 
@@ -62,7 +63,8 @@
 ServletContext servletContext)
 throws IOException, ServletException {
 
-request.getRequestDispatcher(uri).forward(request, response);
+TilesRequestProcessor requestProcessor = getRequestProcessor(
servletContext );
+requestProcessor.doInclude( uri, request, response );
 }
 
 /**
@@ -82,7 +84,8 @@
 ServletContext servletContext)
 throws IOException, ServletException {
 
-request.getRequestDispatcher(uri).include(request, response);
+TilesRequestProcessor requestProcessor = getRequestProcessor(
servletContext );
+requestProcessor.doInclude( uri, request, response );
 }
 
 /**
@@ -96,7 +99,10 @@
 public void doInclude(String uri, PageContext pageContext)
 throws IOException, ServletException {
 
-pageContext.include(uri);
+TilesRequestProcessor requestProcessor = getRequestProcessor(
pageContext.getServletConfig().getServletContext());
+requestProcessor.doInclude( uri, 
+  (HttpServletRequest) pageContext.getRequest(), 
+  (HttpServletResponse) pageContext.getResponse());
 }
 
 /**
@@ -200,4 +206,15 @@
 servletContext.setAttribute(DEFINITIONS_FACTORY, factory);
 }
 
-}
\ No newline at end of file
+/**
+ * Get Tiles RequestProcessor associated to application.
+ * @param servletContext Current servlet context.
+ * @return The [EMAIL PROTECTED] TilesRequestProcessor} for the current 
request.
+ */
+protected TilesRequestProcessor getRequestProcessor(
+ServletContext servletContext) {
+
+return (Til

DO NOT REPLY [Bug 35703] - TilesUtilImpl doInclude() should call TilesRequestProcessor doInclude()... but it doesn't

2005-07-12 Thread 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=35703





--- Additional Comments From [EMAIL PROTECTED]  2005-07-12 14:39 ---
Created an attachment (id=15654)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15654&action=view)
First part of the patch is for TilesRequestProcessor to override
RequestProcessor doInclude() method to allow for calling overloaded methods of
subclasses of TilesRequestProcessor.


-- 
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]



DO NOT REPLY [Bug 35703] - TilesUtilImpl doInclude() should call TilesRequestProcessor doInclude()... but it doesn't

2005-07-12 Thread 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=35703





--- Additional Comments From [EMAIL PROTECTED]  2005-07-12 14:39 ---
Created an attachment (id=15655)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15655&action=view)
Second part is the actual fix for TilesUtilImpl to call TilesRequestProcessor
doInclude() method.


-- 
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]



DO NOT REPLY [Bug 35396] - [taglib] additional attributes for struts html tags

2005-07-12 Thread 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=35396


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
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]



DO NOT REPLY [Bug 32215] - [taglib] Ability to extend Struts tags implementation cleanly

2005-07-12 Thread 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=32215


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-07-12 15:27 ---
see also bug 1598

-- 
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]



struts 1.0.2

2005-07-12 Thread Neti, Sridhar
Hi
 
I would like to know is Struts 1.0.2 still supported?
 
 
Sridhar Neti
Bureau of Criminal Apprehension
1430 Maryland Avenue East 
St. Paul, MN 55106 
717-497-5890(M)
651-793-2713(O)
[EMAIL PROTECTED]
 


Re: struts 1.0.2

2005-07-12 Thread netsql

Neti, Sridhar wrote:

Hi
 
I would like to know is Struts 1.0.2 still supported?
 
 


define supported?


.V


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



Re: Tile question

2005-07-12 Thread Michael Rasmussen
John,
  Questions like this should be directed to the user list.
Thanks,
Michael

On 7/12/05, john mattucci <[EMAIL PROTECTED]> wrote:
> I posted this the other I'm not sure if I'm posting it to the right
> group.
> I'm new to tiles and I was wondering if this is possible.
> I have the following in my tiles definition files
> 
> 
> 
> 
> 
> 
> I would like to use definitions as ActionForwards
> 
>  path="/test"
> type="org.apache.struts...
>  name="success"
> path=".main.Parent"/>
> 
> 
> My question would it be possible to include values to passed to
> ${TopMenu} and ${Footer} in
> 
>  name="success"
> path=".main.Parent"/>
> 
> of the action?
> 
> Thank you all
> 
> 
>

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



RE: Re: struts 1.0.2

2005-07-12 Thread Neti, Sridhar
Hi

Supported means will there be any mailing lists or people out there help
us if we have any issues. Currently we are using 1.0.2 the decision is
to go ahead with 1.0.2 or upgrade it to latest version?

 
Sridhar Neti
[EMAIL PROTECTED]


-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of netsql
Sent: Tuesday, July 12, 2005 10:04 AM
To: dev@struts.apache.org
Subject: Re: struts 1.0.2


Neti, Sridhar wrote:
> Hi
>  
> I would like to know is Struts 1.0.2 still supported?
>  
>  

define supported?


.V


-
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: Re: struts 1.0.2

2005-07-12 Thread Frank W. Zammetti
I think you would be well-served to upgrade.  While the people on this
list tend to be very helpful and knowledgeable and would probably be able
to offer some degree of support for 1.0.2, you may find that those
resources dwindle quicker than you'd like :)

Not to mention the fact that all the things that have been added to Struts
since 1.0.2 would probably be very nice to have available to your project.

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

On Tue, July 12, 2005 11:10 am, Neti, Sridhar said:
> Hi
>
> Supported means will there be any mailing lists or people out there help
> us if we have any issues. Currently we are using 1.0.2 the decision is
> to go ahead with 1.0.2 or upgrade it to latest version?
>
>
> Sridhar Neti
> [EMAIL PROTECTED]
>
>
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of netsql
> Sent: Tuesday, July 12, 2005 10:04 AM
> To: dev@struts.apache.org
> Subject: Re: struts 1.0.2
>
>
> Neti, Sridhar wrote:
>> Hi
>>
>> I would like to know is Struts 1.0.2 still supported?
>>
>>
>
> define supported?
>
>
> .V
>
>
> -
> 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: Re: struts 1.0.2

2005-07-12 Thread Neti, Sridhar
Thanks for the support and I will be in touch with this list for any
help.

 
Sridhar Neti
[EMAIL PROTECTED]


-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 12, 2005 10:30 AM
To: Struts Developers List
Cc: Struts Developers List
Subject: RE: Re: struts 1.0.2


I think you would be well-served to upgrade.  While the people on this
list tend to be very helpful and knowledgeable and would probably be
able to offer some degree of support for 1.0.2, you may find that those
resources dwindle quicker than you'd like :)

Not to mention the fact that all the things that have been added to
Struts since 1.0.2 would probably be very nice to have available to your
project.

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

On Tue, July 12, 2005 11:10 am, Neti, Sridhar said:
> Hi
>
> Supported means will there be any mailing lists or people out there 
> help us if we have any issues. Currently we are using 1.0.2 the 
> decision is to go ahead with 1.0.2 or upgrade it to latest version?
>
>
> Sridhar Neti
> [EMAIL PROTECTED]
>
>
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of netsql
> Sent: Tuesday, July 12, 2005 10:04 AM
> To: dev@struts.apache.org
> Subject: Re: struts 1.0.2
>
>
> Neti, Sridhar wrote:
>> Hi
>>
>> I would like to know is Struts 1.0.2 still supported?
>>
>>
>
> define supported?
>
>
> .V
>
>
> -
> 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: Tiles

2005-07-12 Thread David Geary

Le 05-07-11 à 21:04, James Mitchell a écrit :


Sorry if I've been out of the loop.

What's going on with Tiles under sandbox/trunk?  Last I heard, we  
were going to change Tiles (HEAD) to be free of it's dependency on  
Struts.  What is under the sandbox?  It seems like a modification  
based off of some old version of Tiles.  Am I missing something?


It's a standalone version of Tiles taken from Struts 1.1. When I  
originally ripped it out of Struts, it never occurred to me that it  
might be folded back into Struts at a later time, so I wasn't  
concerned about losing the few Tiles code changes from 1.1 to 1.2.  
However, it appears that the strategy now is to unplug the current  
version of Tiles from Struts and hook it up to the standalone  
version, so those changes (along with CVS history) are suddenly  
important.


Neil Pemberton pointed out the stale code and loss of history in a  
post to this list shortly after I committed standalone Tiles to the  
sandbox and I agreed to fix it. As a matter of fact, I'd appreciate  
some feedback on how to do that. AFAICT, I'll have to svn copy from  
the current version of Struts and then re-rip Tiles from that tree.  
If anyone has a power-SVN solution that would avoid that pain, I'd  
like to hear about it.



david




--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM:   jmitchtx
MSN:   [EMAIL PROTECTED]
Skype: jmitchtx



-
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: Tiles

2005-07-12 Thread David Geary

Le 05-07-11 à 23:54, Craig McClanahan a écrit :


On 7/11/05, James Mitchell <[EMAIL PROTECTED]> wrote:


I assumed that was the case.

So, what happens now?  Does org.apache.tiles continue to grow  
under the

sandbox?


We should try to minimize growth until we align it with the current  
version of Struts Tiles because it seems as though we're going to  
have to replace files (see my other reply to this thread's original  
email). I'm keeping track of changes I see here, but things could get  
out of hand if we were to diverge significantly before updating what  
we currently have.



Can I move tiles/trunk to some legacy location that is not pulled
into current/, then move sandbox/tiles to where the original was?


Eventually we want to do something like that, but we need to align  
with the current Struts Tiles first.




I'm not sure I understand what the plan is here, surely we are not  
going to

maintain 2 sets of Tiles code...are we?


We definitely don't want to maintain two sets of code.  As David Geary
likes to acronym-ize :-), DRY ("don't repeat yourself").

IIRC correcty, the original plan was along the lines of:

* Establish a stand alone releasable artifact for Tiles, not
  dependent on the Struts 1.x core.  (This involves both
  technology and community; so it makes sense to start
  within the Struts community and just adapt the technology).


I take it this means there will be someplace in Apache where you can  
download the tiles-core.jar. Is that correct?




* Once the standalone Tiles is mature and functional,
  migrate Struts to support it (while maintaining backwards
  compatibility for the original mechanisms, even if deprecated,
  for a reasonable amount of time).


Standalone Tiles is mature and functional now, isn't it? I think the  
issues are that it's out of synch with the current Struts Tiles.



* Encourage other frameworks that have wanted a reusable
  templating architecture to adopt standalone Tlles.

* If/when it makes sense, launch Tiles as a separate Jakarta
  subproject or Apache top level project.

We're on the way towards the first goal ... the immmediate next steps
are to ensure that the standalone Tiles has *all* the functionality of
the current integrated version (and none of the bugs, of course :-).
Then, it's up to the developers focused on Struts 1.x to define a
migration strategy (possibly through re-implementing the
Struts-dependent org.apache.struts.tiles classes as wrappers around
the corresponding org.apache.tiles classes, or by supporting both the
new and old, and deprecating the old).

But we're only at the beginning of this path.  Martin gave us a great
TODO list as a starting point in an earlier thread; I'm going to focus
some attention on addressing those issues.


I'm glad to hear that.  8-)


david




James Mitchell



Craig

-
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: Tiles

2005-07-12 Thread Craig McClanahan
On 7/12/05, David Geary <[EMAIL PROTECTED]> wrote:
> Le 05-07-11 à 23:54, Craig McClanahan a écrit :
> 
> > On 7/11/05, James Mitchell <[EMAIL PROTECTED]> wrote:
> >
> >> I assumed that was the case.
> >>
> >> So, what happens now?  Does org.apache.tiles continue to grow
> >> under the
> >> sandbox?
> 
> We should try to minimize growth until we align it with the current
> version of Struts Tiles because it seems as though we're going to
> have to replace files (see my other reply to this thread's original
> email). I'm keeping track of changes I see here, but things could get
> out of hand if we were to diverge significantly before updating what
> we currently have.

Agreed that we should move quickly on convergence.

> 
> >> Can I move tiles/trunk to some legacy location that is not pulled
> >> into current/, then move sandbox/tiles to where the original was?
> 
> Eventually we want to do something like that, but we need to align
> with the current Struts Tiles first.
> 
> >>
> >> I'm not sure I understand what the plan is here, surely we are not
> >> going to
> >> maintain 2 sets of Tiles code...are we?
> >
> > We definitely don't want to maintain two sets of code.  As David Geary
> > likes to acronym-ize :-), DRY ("don't repeat yourself").
> >
> > IIRC correcty, the original plan was along the lines of:
> >
> > * Establish a stand alone releasable artifact for Tiles, not
> >   dependent on the Struts 1.x core.  (This involves both
> >   technology and community; so it makes sense to start
> >   within the Struts community and just adapt the technology).
> 
> I take it this means there will be someplace in Apache where you can
> download the tiles-core.jar. Is that correct?
> 

That would certainly be a goal for having Tiles standalone in the
first place -- it would need to be something we (Struts project) can
vote on and release as a separate artifact.  That same artifcat could
then be incorporated into an overall Struts 1.x release, or
incorporated in non-Struts-1.x projects as well.

> >
> > * Once the standalone Tiles is mature and functional,
> >   migrate Struts to support it (while maintaining backwards
> >   compatibility for the original mechanisms, even if deprecated,
> >   for a reasonable amount of time).
> 
> Standalone Tiles is mature and functional now, isn't it? I think the
> issues are that it's out of synch with the current Struts Tiles.
> 

Seems so ... but I was just reiterating the original thinking.

> > * Encourage other frameworks that have wanted a reusable
> >   templating architecture to adopt standalone Tlles.
> >
> > * If/when it makes sense, launch Tiles as a separate Jakarta
> >   subproject or Apache top level project.
> >
> > We're on the way towards the first goal ... the immmediate next steps
> > are to ensure that the standalone Tiles has *all* the functionality of
> > the current integrated version (and none of the bugs, of course :-).
> > Then, it's up to the developers focused on Struts 1.x to define a
> > migration strategy (possibly through re-implementing the
> > Struts-dependent org.apache.struts.tiles classes as wrappers around
> > the corresponding org.apache.tiles classes, or by supporting both the
> > new and old, and deprecating the old).
> >
> > But we're only at the beginning of this path.  Martin gave us a great
> > TODO list as a starting point in an earlier thread; I'm going to focus
> > some attention on addressing those issues.
> 
> I'm glad to hear that.  8-)
> 
> 
> david

Craig

> >
> >
> >> James Mitchell
> >>
> >
> > Craig
> >
> > -
> > 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]



[shale] [clay] Problem with updating model

2005-07-12 Thread Sergey Smirnov
I have got a problem with updating model when clay based component is used.
As a test case I have two pages. On the first page I ask for  name. Then, on 
the second page, I print it.

When I have on the first page:
   




Everything works properly. However, when I replace inputText with clay style:

   




It shows the init value from the bean, but does not update the bean when the 
changed value is submitted.

clay-config.xml has:

 



 

faces-config.xml has:

...
 
  myuser
  demo.User
  request
  
   firstName
   java.lang.String
   John
  
 
...

Actually, I incorporated those test stuff inside the shale-use-case application 
(07/08/05 nightly build). So, the rest configuration is from the original 
shale-use-case environment.

Do I miss something important here?

--
Sergey



DO NOT REPLY [Bug 35697] - [taglib] struts bean:write bug

2005-07-12 Thread 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=35697


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-07-13 02:50 ---
Error Example

==

<%@ page contentType="text/html; charset=GBK" %>

<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>

 

 



 



report

 



 



  

  

  

  



 



=

Throw Exception

=

org.apache.jasper.JasperException: Cannot find bean dcjcjlwhActionForm in scope 
request


at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:254)


at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)


at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)


at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)


at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)


at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)


at framework.web.AbstractServletFilterBase.doFilter
(AbstractServletFilterBase.java:44)


at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:213)


at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)


at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:256)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)


at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)


at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)


at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)


at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2416)


at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)


at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:171)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)


at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)


at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)


at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)


at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)


at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)


at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:601)


at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio
n(Http11Protocol.java:392)


at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:565)


at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:619)


at java.lang.Thread.run(Thread.java:534)


=

Question

=
precondition [dcjcjlwhActionForm] in request 

error position   if src="" error , if src="xxx" ok

=

My Email:[EMAIL PROTECTED] 

 

Thank your



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You

DO NOT REPLY [Bug 35697] - [taglib] struts bean:write bug

2005-07-12 Thread 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=35697





--- Additional Comments From [EMAIL PROTECTED]  2005-07-13 02:51 ---
Error Example

==

<%@ page contentType="text/html; charset=GBK" %>

<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>

 

 



 



report

 



 



  

  

  

  



 



=

Throw Exception

=

org.apache.jasper.JasperException: Cannot find bean dcjcjlwhActionForm in scope 
request


at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:254)


at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)


at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)


at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)


at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)


at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)


at framework.web.AbstractServletFilterBase.doFilter
(AbstractServletFilterBase.java:44)


at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:213)


at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)


at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:256)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)


at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)


at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)


at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)


at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2416)


at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)


at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:171)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)


at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)


at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)


at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)


at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)


at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)


at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)


at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:601)


at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio
n(Http11Protocol.java:392)


at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:565)


at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:619)


at java.lang.Thread.run(Thread.java:534)


=

Question

=

  src="" error , src="123" ok

=

My Email:[EMAIL PROTECTED] 

 

Thank your

 

 

 


-- 
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]



DO NOT REPLY [Bug 35697] - [taglib] struts bean:write bug

2005-07-12 Thread 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=35697


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-07-13 04:24 ---
I fail to see how this is a bug.  You obviously did not an ActionForm under the
key (in any scope) that you told the tag it would be under.

Please subscribe to the users list and ask for help there.

-- 
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: [shale] [clay] Problem with updating model

2005-07-12 Thread gvanmatre
Hi Sergey,

>I have got a problem with updating model when clay based component is used.
>As a test case I have two pages. On the first page I ask for  name. Then, on 
>the 
>second page, I print it.
>
>When I have on the first page:
>   
>
>
>
>
>Everything works properly. However, when I replace inputText with clay style:
>
>   
>
>
>
>
>It shows the init value from the bean, but does not update the bean when the 
>changed value is submitted.
>
>clay-config.xml has:
>
> 
>
>
>
> 
>
>faces-config.xml has:
>
>...
> 
>  myuser
>  demo.User
>  request
>  
>   firstName
>   java.lang.String
>   John
>  
> 
>...
>Actually, I incorporated those test stuff inside the shale-use-case 
>application 
>(07/08/05 nightly build). So, the rest configuration is from the original 
>shale-use-case environment.

You should look in the use case builds after 7/10.  Craig applied a patch to 
the rolodex example late Sat. having HTML tapestry like templating.  

Presently, the HTML templating has to be included as a subtree within a JSP 
page.  I'm near to posting a bugzilla ticket with a clay view handler that will 
allow for full html view templating :-)

>
>Do I miss something important here?

Try adding the "userValueLateBinding" attribute to the "set" node.
 
This attribute,  tells clay to pass a ValueBinding object to the target 
component. Otherwise, the resulting literal expression will be passed.  I'm 
guess that your navigation rule is not a redirect since your bean is in request 
scope.

For some of the base components like the outputText, this attribute is set as a 
default. This means that all components that extend "outputText" will inherit 
the default attribute with the name of "value" having "userValueLateBinding" 
set to "true". 

The default clay configuration file, view-config.xml, can be found in META-INF 
of the shale-clay.jar.

There is a similar attribute, "useMethodLateBinding" for method binding. The 
basis for these attributes is that there is a predefined contract between a 
component's JSP tag and the corresponding faces component. Since Clay is a 
stand-in for the JSP faces tags, these attributes allow you to specify what get 
passed to the component's properties - as an expression object or a literal 
value.


  
   
  


Gary
>
>--
>Sergey