Re: Clay & Scxml

[Rahul Akolkar]

On Tue, May 26, 2009 at 5:22 AM, Dave Hagan  wrote:
> Hi
>  We have been developing with Shale for the last 3 years and have found the
> shale Clay & the Scxml dialogs extremely useful - Can Clay and Scxml be used
> with Myfaces and other frameworks as a stand alone piece.


I'll speak to the SCXML dialogs -- yes, definitely, the dialogs can be
used with any kind of views really, be it MyFaces or any other view
layer technologies.

Please note that Shale has recently moved to the Apache Attic, more on
that here [1]. This basically means that no further Shale development
is planned (as part of the Apache Shale project). Ofcourse, old
releases will continue to be available for download.

-Rahul

[1] http://attic.apache.org/projects/shale.html


> Regards
> Dave Hagan
>

Re: Error Handling

[Cyril Bouteille]

Tim, it's likely because the error happened during the rendering phase 
after the beginning of the HTML has already been flushed on the response 
socket...

You have a couple of options:
1) move your offending code into prerender event and add an  
very high in your page markup so it's executed before a lot of markup is 
written on the socket, or
2) increase the page buffer size to be larger than the content before 
your exception is triggered, e.g. <%@ page buffer="10kb" %>

Hope it helps,
--
Cyril Bouteille
TravelMuse, Inc.

Tim Corless wrote:

I found that I have a NullPointerException in the my prerender code of my 
ViewController but I don't get an error page.  I have set 
EXCEPTION_DISPATCH_PATH and it looks like when Shale does the redirect to my 
error page, the redirect causes an IllegalStateException.  I have MyFaces 
default error handling on but I don't get an error page at all.  Does anyone 
know how I get my error page to display?
 


org.apache.shale.view.EXCEPTION_DISPATCH_PATH
/actions/app/Error.action

 
[2009-05-05 08:39:27,566] [WebContainer : 20] *ERROR* org.apache.myfaces.lifecycle.PhaseListenerManager - Exception in PhaseListener RENDER_RESPONSE(6) afterPhase

java.lang.IllegalStateException: Cannot forward. Response already committed.
at 
com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:157)
at 
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:425)
at 
org.apache.shale.view.faces.ViewPhaseListener.afterPhaseExceptionCheck(ViewPhaseListener.java:202)
 
Thanks

-Tim
  





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ANNOUNCE] Apache Shale To Move To the Attic

[Kito Mann]

On Fri, May 1, 2009 at 2:51 PM, Cyril Bouteille wrote:

>  It provides the missing C in MVC of JSF for GET requests. :-) A hook in
> the JSP where you can declare which managed bean should be initialized for
> rendering.
> Typically high in your JSP,  would call
> NameOfYourBean.prerender() event. Each page is in control of what beans it
> needs w/o maintaining any additional mapping file or worry about URLs. It
> provides you also with the flexibility to do conditional initialization with
> verbatims etc.
> I'll check your link, thanks. It looks like the hook is the other direction
> with orchestra where the bean maps to JSPs.
>

Ah, I see. Nice. FYI, the phaseListener feature in JSF 1.2 is more
fine-grained than I mentioned; you can reference a specific method via a
method expression for beforePhase and afterPhase. See
http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/tlddocs/f/view.html.


>
> Kito Mann wrote:
>
> Hello Cyril,
>
> The Orchestra ViewController can definitely handle this. See:
> http://myfaces.apache.org/orchestra/myfaces-orchestra-core/viewController.html
> .
>
> I'm not too familiar with the  tag -- how does that work?
>
> ---
> Kito D. Mann -- Author, JavaServer Faces in Action
> http://twitter.com/kito99  http://twitter.com/jsfcentral
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> +1 203-404-4848 x3
>
>
> On Tue, Apr 28, 2009 at 5:39 PM, Cyril Bouteille wrote:
>
>> Hi Kito, by VC feature I meant essentially the prerender event for
>> processing GET requests. I couldn't see such hook from Orchestra's overview.
>> Does it have such a feature?
>> Writing custom PhaseListeners kicking in logic based on URLs gets a bit
>> old... :) Shale's declarative  is great and much cleaner.
>> Anything else like that out there?
>>
>> Kito Mann wrote:
>>
>>> On Tue, Apr 28, 2009 at 12:44 PM, Cyril Bouteille >> >wrote:
>>>
>>>
>>>
 This is sad news! Can you please recommend alternative projects for
 migration of deployed View-Controller and Remote features? Thanks.


>>>
>>>
>>> MyFaces Apache Orchestra has a view controller feature as well, and you
>>> with
>>> JSF 1.2 sometimes a PhaseListener associated with a particular view can
>>> yield similar results:
>>>
>>> >> afterPhase="#{myBean.afterPhase}">
>>> ...
>>> 
>>>
>>> The remoting features are a different story, though. JSF 2.0 has most of
>>> the
>>> Shale features (excluding the dialog framework and test framework). It
>>> handles most of the use cases Shale Remoting handles (i.e. resource
>>> mangement) but doesn't allow you to call arbitrary methods in the same
>>> manner.
>>>
>>>
>>>
 Greg Reddin wrote:



> This is a heads up for the Shale user community that the Shale PMC has
> voted to move the project to the Attic. This means that the Shale
> developers (more formally its Project Management Committee) have voted
> to retire Shale and move the responsibility for its oversight over to
> the Attic project.
>
> The MyFaces community has expressed interest in continuing development
> of the Shale-Test module and the Shale PMC will work with MyFaces to
> migrate this piece of the codebase.. Look for further announcements to
> that regard in the near future.
>
> You can read more about the Apache Attic at http://attic.apache.org.
>
> You can follow the progress of the move at
>
>   https://issues.apache.org/jira/browse/ATTIC-2 if you so wish.
>
> On behalf of the Apache Shale PMC, Thanks!
>
> Greg Reddin
>
>
>
>

>>
>
> --
> [image: TravelMuse Logo] Cyril Bouteille
>  VP, Engineering
>
>  TravelMuse, Inc.
>  4410 El Camino Real, Suite 102
> Los Altos, CA 94022
>  Site: http://www.travelmuse.com (RSS ) | 
> Cyril's
> TravelMuse 
> Blogs: 
> Company(
> RSS)
> | TravelMusings (
> RSS )
> | Photo  
> (RSS
> )
> Facebook: 
> Page|
> App 
> --
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in err

Re: [ANNOUNCE] Apache Shale To Move To the Attic

[Cyril Bouteille]

It provides the missing C in MVC of JSF for GET requests.  :-) A hook in 
the JSP where you can declare which managed bean should be initialized 
for rendering.
Typically high in your JSP,  would 
call NameOfYourBean.prerender() event. Each page is in control of what 
beans it needs w/o maintaining any additional mapping file or worry 
about URLs or having to recompile java on changes. It provides you also 
with the flexibility to do conditional initialization with verbatims etc.
I'll check your link, thanks. It looks like the hook is the other 
direction with orchestra where the bean maps to JSPs.


Kito Mann wrote:

Hello Cyril,

The Orchestra ViewController can definitely handle this. See: 
http://myfaces.apache.org/orchestra/myfaces-orchestra-core/viewController.html.


I'm not too familiar with the  tag -- how does that work?

---
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99  http://twitter.com/jsfcentral
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3


On Tue, Apr 28, 2009 at 5:39 PM, Cyril Bouteille > wrote:


Hi Kito, by VC feature I meant essentially the prerender event for
processing GET requests. I couldn't see such hook from Orchestra's
overview. Does it have such a feature?
Writing custom PhaseListeners kicking in logic based on URLs gets
a bit old... :) Shale's declarative  is great and
much cleaner. Anything else like that out there?





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ANNOUNCE] Apache Shale To Move To the Attic

[Kito Mann]

FYI, I wrote a new blog entry about this:
http://blogs.jsfcentral.com/editorsdesk/entry/shale_in_the_attic
---
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99  http://twitter.com/jsfcentral
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3


On Fri, May 1, 2009 at 2:28 PM, Kito Mann  wrote:

> Hello Cyril,
>
> The Orchestra ViewController can definitely handle this. See:
> http://myfaces.apache.org/orchestra/myfaces-orchestra-core/viewController.html
> .
>
> I'm not too familiar with the  tag -- how does that work?
>
> ---
> Kito D. Mann -- Author, JavaServer Faces in Action
> http://twitter.com/kito99  http://twitter.com/jsfcentral
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> +1 203-404-4848 x3
>
>
>
> On Tue, Apr 28, 2009 at 5:39 PM, Cyril Bouteille wrote:
>
>> Hi Kito, by VC feature I meant essentially the prerender event for
>> processing GET requests. I couldn't see such hook from Orchestra's overview.
>> Does it have such a feature?
>> Writing custom PhaseListeners kicking in logic based on URLs gets a bit
>> old... :) Shale's declarative  is great and much cleaner.
>> Anything else like that out there?
>>
>>
>> Kito Mann wrote:
>>
>>> On Tue, Apr 28, 2009 at 12:44 PM, Cyril Bouteille >> >wrote:
>>>
>>>
>>>
 This is sad news! Can you please recommend alternative projects for
 migration of deployed View-Controller and Remote features? Thanks.


>>>
>>>
>>> MyFaces Apache Orchestra has a view controller feature as well, and you
>>> with
>>> JSF 1.2 sometimes a PhaseListener associated with a particular view can
>>> yield similar results:
>>>
>>> >> afterPhase="#{myBean.afterPhase}">
>>> ...
>>> 
>>>
>>> The remoting features are a different story, though. JSF 2.0 has most of
>>> the
>>> Shale features (excluding the dialog framework and test framework). It
>>> handles most of the use cases Shale Remoting handles (i.e. resource
>>> mangement) but doesn't allow you to call arbitrary methods in the same
>>> manner.
>>>
>>>
>>>
 Greg Reddin wrote:



> This is a heads up for the Shale user community that the Shale PMC has
> voted to move the project to the Attic. This means that the Shale
> developers (more formally its Project Management Committee) have voted
> to retire Shale and move the responsibility for its oversight over to
> the Attic project.
>
> The MyFaces community has expressed interest in continuing development
> of the Shale-Test module and the Shale PMC will work with MyFaces to
> migrate this piece of the codebase.. Look for further announcements to
> that regard in the near future.
>
> You can read more about the Apache Attic at http://attic.apache.org.
>
> You can follow the progress of the move at
>
>   https://issues.apache.org/jira/browse/ATTIC-2 if you so wish.
>
> On behalf of the Apache Shale PMC, Thanks!
>
> Greg Reddin
>
>
>
>

>>
>

Re: [ANNOUNCE] Apache Shale To Move To the Attic

[Kito Mann]

Hello Cyril,

The Orchestra ViewController can definitely handle this. See:
http://myfaces.apache.org/orchestra/myfaces-orchestra-core/viewController.html
.

I'm not too familiar with the  tag -- how does that work?

---
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99  http://twitter.com/jsfcentral
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3


On Tue, Apr 28, 2009 at 5:39 PM, Cyril Bouteille wrote:

> Hi Kito, by VC feature I meant essentially the prerender event for
> processing GET requests. I couldn't see such hook from Orchestra's overview.
> Does it have such a feature?
> Writing custom PhaseListeners kicking in logic based on URLs gets a bit
> old... :) Shale's declarative  is great and much cleaner.
> Anything else like that out there?
>
>
> Kito Mann wrote:
>
>> On Tue, Apr 28, 2009 at 12:44 PM, Cyril Bouteille > >wrote:
>>
>>
>>
>>> This is sad news! Can you please recommend alternative projects for
>>> migration of deployed View-Controller and Remote features? Thanks.
>>>
>>>
>>
>>
>> MyFaces Apache Orchestra has a view controller feature as well, and you
>> with
>> JSF 1.2 sometimes a PhaseListener associated with a particular view can
>> yield similar results:
>>
>> > afterPhase="#{myBean.afterPhase}">
>> ...
>> 
>>
>> The remoting features are a different story, though. JSF 2.0 has most of
>> the
>> Shale features (excluding the dialog framework and test framework). It
>> handles most of the use cases Shale Remoting handles (i.e. resource
>> mangement) but doesn't allow you to call arbitrary methods in the same
>> manner.
>>
>>
>>
>>> Greg Reddin wrote:
>>>
>>>
>>>
 This is a heads up for the Shale user community that the Shale PMC has
 voted to move the project to the Attic. This means that the Shale
 developers (more formally its Project Management Committee) have voted
 to retire Shale and move the responsibility for its oversight over to
 the Attic project.

 The MyFaces community has expressed interest in continuing development
 of the Shale-Test module and the Shale PMC will work with MyFaces to
 migrate this piece of the codebase.. Look for further announcements to
 that regard in the near future.

 You can read more about the Apache Attic at http://attic.apache.org.

 You can follow the progress of the move at

   https://issues.apache.org/jira/browse/ATTIC-2 if you so wish.

 On behalf of the Apache Shale PMC, Thanks!

 Greg Reddin




>>>
>

Re : Re : [ANNOUNCE] Apache Shale To Move To the Attic

[Adrian Gonzalez]

I'm not used to Shale dialogs.

Perhaps using jpdl ? (and not jbpm !) (jpdl = page flows) 
http://docs.jboss.com/seam/2.1.1.GA/reference/en-US/html/jbpm.html


We've used jpdl once 1.5 year ago, there where issues concerning exception 
handling (not done at pages.xml).
But it has surely be resolved since.



De : "mario.buonop...@accenture.com" 
À : user@shale.apache.org
Envoyé le : Mercredi, 29 Avril 2009, 9h32mn 10s
Objet : RE: Re : [ANNOUNCE] Apache Shale To Move To the Attic

Hi, how can migrate Shale dialogs in seam?

Mario

-Original Message-
From: Adrian Gonzalez [mailto:adr_gonza...@yahoo.fr] 
Sent: 29 aprile 2009 00.07
To: user@shale.apache.org
Subject: Re : [ANNOUNCE] Apache Shale To Move To the Attic

You should take a serious look at seam (at least read all the documentation if 
you need to change your codebase) before taking another framework on top of jsf.

http://docs.jboss.com/seam/2.1.1.GA/reference/en-US/html/


The framework is very powerfull (but complicated, and you should do perf. 
benchmarks).
To use it with facelets / ajax4jsf / richfaces.

conversation management
get functionnality and page actions
remoting (proprietary protocol)
powerfull navigation with exception handling
good jpa (urgh... hibernate) integration
validation with Hibernate Validator (this is a goog one !)
security (authentication / authz)
spring integration if need be

and much more...



De : Cyril Bouteille 
À : Greg Reddin 
Cc : "user@shale.apache.org" 
Envoyé le : Mardi, 28 Avril 2009, 23h31mn 13s
Objet : Re: [ANNOUNCE] Apache Shale To Move To the Attic

Hi Greg, what features of Seam do you feel match Shale's VC or Remoting?
I also understand ajax4jsf to be returning only HTML fragments per 
architecture. We've a lot of Shale Remoting function returning JSON and I'm not 
sure how we would do that in RichFaces...
We do have a couple of outstanding bugs with Shale and unfortunately not much 
time to contribute :-( , so folks like me will have to migrate to some other 
framework that's still actively maintained.

Greg Reddin wrote:
> On Tue, Apr 28, 2009 at 11:44 AM, Cyril Bouteille  
> wrote:
>  
>> This is sad news! Can you please recommend alternative projects for
>> migration of deployed View-Controller and Remote features? Thanks.
>>
> 
> Just my viewpoint: probably your best bet would be to migrate to Seam
> and/or ajax4jsf.
> 
> But if you just don't feel like leaving Shale... This doesn't mean the
> code is going to disappear. The code will be housed in the Apache
> Attic svn. I'm not sure about existing releases, but I doubt they will
> be removed from Maven repos, etc. If you feel like the code needs
> further improvement feel free to start it back up at Google Code or
> elsewhere. The only caveat to forking is that ASF still holds the
> Apache Shale trademark so you'd have to come up with a different name.
> 
> Thanks,
> Greg
>  


  


This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.



  

RE: Re : [ANNOUNCE] Apache Shale To Move To the Attic

[mario.buonopane]

Hi, how can migrate Shale dialogs in seam?

Mario

-Original Message-
From: Adrian Gonzalez [mailto:adr_gonza...@yahoo.fr] 
Sent: 29 aprile 2009 00.07
To: user@shale.apache.org
Subject: Re : [ANNOUNCE] Apache Shale To Move To the Attic

You should take a serious look at seam (at least read all the documentation if 
you need to change your codebase) before taking another framework on top of jsf.

http://docs.jboss.com/seam/2.1.1.GA/reference/en-US/html/


The framework is very powerfull (but complicated, and you should do perf. 
benchmarks).
To use it with facelets / ajax4jsf / richfaces.

conversation management
get functionnality and page actions
remoting (proprietary protocol)
powerfull navigation with exception handling
good jpa (urgh... hibernate) integration
validation with Hibernate Validator (this is a goog one !)
security (authentication / authz)
spring integration if need be

and much more...



De : Cyril Bouteille 
À : Greg Reddin 
Cc : "user@shale.apache.org" 
Envoyé le : Mardi, 28 Avril 2009, 23h31mn 13s
Objet : Re: [ANNOUNCE] Apache Shale To Move To the Attic

Hi Greg, what features of Seam do you feel match Shale's VC or Remoting?
I also understand ajax4jsf to be returning only HTML fragments per 
architecture. We've a lot of Shale Remoting function returning JSON and I'm not 
sure how we would do that in RichFaces...
We do have a couple of outstanding bugs with Shale and unfortunately not much 
time to contribute :-( , so folks like me will have to migrate to some other 
framework that's still actively maintained.

Greg Reddin wrote:
> On Tue, Apr 28, 2009 at 11:44 AM, Cyril Bouteille  
> wrote:
>  
>> This is sad news! Can you please recommend alternative projects for
>> migration of deployed View-Controller and Remote features? Thanks.
>>
> 
> Just my viewpoint: probably your best bet would be to migrate to Seam
> and/or ajax4jsf.
> 
> But if you just don't feel like leaving Shale... This doesn't mean the
> code is going to disappear. The code will be housed in the Apache
> Attic svn. I'm not sure about existing releases, but I doubt they will
> be removed from Maven repos, etc. If you feel like the code needs
> further improvement feel free to start it back up at Google Code or
> elsewhere. The only caveat to forking is that ASF still holds the
> Apache Shale trademark so you'd have to come up with a different name.
> 
> Thanks,
> Greg
>  


  


This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

Re : [ANNOUNCE] Apache Shale To Move To the Attic

[Adrian Gonzalez]

You should take a serious look at seam (at least read all the documentation if 
you need to change your codebase) before taking another framework on top of jsf.

http://docs.jboss.com/seam/2.1.1.GA/reference/en-US/html/


The framework is very powerfull (but complicated, and you should do perf. 
benchmarks).
To use it with facelets / ajax4jsf / richfaces.

conversation management
get functionnality and page actions
remoting (proprietary protocol)
powerfull navigation with exception handling
good jpa (urgh... hibernate) integration
validation with Hibernate Validator (this is a goog one !)
security (authentication / authz)
spring integration if need be

and much more...



De : Cyril Bouteille 
À : Greg Reddin 
Cc : "user@shale.apache.org" 
Envoyé le : Mardi, 28 Avril 2009, 23h31mn 13s
Objet : Re: [ANNOUNCE] Apache Shale To Move To the Attic

Hi Greg, what features of Seam do you feel match Shale's VC or Remoting?
I also understand ajax4jsf to be returning only HTML fragments per 
architecture. We've a lot of Shale Remoting function returning JSON and I'm not 
sure how we would do that in RichFaces...
We do have a couple of outstanding bugs with Shale and unfortunately not much 
time to contribute :-( , so folks like me will have to migrate to some other 
framework that's still actively maintained.

Greg Reddin wrote:
> On Tue, Apr 28, 2009 at 11:44 AM, Cyril Bouteille  
> wrote:
>  
>> This is sad news! Can you please recommend alternative projects for
>> migration of deployed View-Controller and Remote features? Thanks.
>>
> 
> Just my viewpoint: probably your best bet would be to migrate to Seam
> and/or ajax4jsf.
> 
> But if you just don't feel like leaving Shale... This doesn't mean the
> code is going to disappear. The code will be housed in the Apache
> Attic svn. I'm not sure about existing releases, but I doubt they will
> be removed from Maven repos, etc. If you feel like the code needs
> further improvement feel free to start it back up at Google Code or
> elsewhere. The only caveat to forking is that ASF still holds the
> Apache Shale trademark so you'd have to come up with a different name.
> 
> Thanks,
> Greg
>  


  

Re: [ANNOUNCE] Apache Shale To Move To the Attic

[Cyril Bouteille]

Hi Kito, by VC feature I meant essentially the prerender event for 
processing GET requests. I couldn't see such hook from Orchestra's 
overview. Does it have such a feature?
Writing custom PhaseListeners kicking in logic based on URLs gets a bit 
old... :) Shale's declarative  is great and much cleaner. 
Anything else like that out there?


Kito Mann wrote:

On Tue, Apr 28, 2009 at 12:44 PM, Cyril Bouteille wrote:

  

This is sad news! Can you please recommend alternative projects for
migration of deployed View-Controller and Remote features? Thanks.




MyFaces Apache Orchestra has a view controller feature as well, and you with
JSF 1.2 sometimes a PhaseListener associated with a particular view can
yield similar results:


...


The remoting features are a different story, though. JSF 2.0 has most of the
Shale features (excluding the dialog framework and test framework). It
handles most of the use cases Shale Remoting handles (i.e. resource
mangement) but doesn't allow you to call arbitrary methods in the same
manner.

  

Greg Reddin wrote:



This is a heads up for the Shale user community that the Shale PMC has
voted to move the project to the Attic. This means that the Shale
developers (more formally its Project Management Committee) have voted
to retire Shale and move the responsibility for its oversight over to
the Attic project.

The MyFaces community has expressed interest in continuing development
of the Shale-Test module and the Shale PMC will work with MyFaces to
migrate this piece of the codebase.. Look for further announcements to
that regard in the near future.

You can read more about the Apache Attic at http://attic.apache.org.

You can follow the progress of the move at

   https://issues.apache.org/jira/browse/ATTIC-2 if you so wish.

On behalf of the Apache Shale PMC, Thanks!

Greg Reddin


  




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ANNOUNCE] Apache Shale To Move To the Attic

[Cyril Bouteille]

Hi Greg, what features of Seam do you feel match Shale's VC or Remoting?
I also understand ajax4jsf to be returning only HTML fragments per 
architecture. We've a lot of Shale Remoting function returning JSON and 
I'm not sure how we would do that in RichFaces...
We do have a couple of outstanding bugs with Shale and unfortunately not 
much time to contribute :-( , so folks like me will have to migrate to 
some other framework that's still actively maintained.


Greg Reddin wrote:

On Tue, Apr 28, 2009 at 11:44 AM, Cyril Bouteille  wrote:
  

This is sad news! Can you please recommend alternative projects for
migration of deployed View-Controller and Remote features? Thanks.



Just my viewpoint: probably your best bet would be to migrate to Seam
and/or ajax4jsf.

But if you just don't feel like leaving Shale... This doesn't mean the
code is going to disappear. The code will be housed in the Apache
Attic svn. I'm not sure about existing releases, but I doubt they will
be removed from Maven repos, etc. If you feel like the code needs
further improvement feel free to start it back up at Google Code or
elsewhere. The only caveat to forking is that ASF still holds the
Apache Shale trademark so you'd have to come up with a different name.

Thanks,
Greg
  




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ANNOUNCE] Apache Shale To Move To the Attic

[Kito Mann]

On Tue, Apr 28, 2009 at 12:44 PM, Cyril Bouteille wrote:

> This is sad news! Can you please recommend alternative projects for
> migration of deployed View-Controller and Remote features? Thanks.


MyFaces Apache Orchestra has a view controller feature as well, and you with
JSF 1.2 sometimes a PhaseListener associated with a particular view can
yield similar results:


...


The remoting features are a different story, though. JSF 2.0 has most of the
Shale features (excluding the dialog framework and test framework). It
handles most of the use cases Shale Remoting handles (i.e. resource
mangement) but doesn't allow you to call arbitrary methods in the same
manner.

>
>
> Greg Reddin wrote:
>
>> This is a heads up for the Shale user community that the Shale PMC has
>> voted to move the project to the Attic. This means that the Shale
>> developers (more formally its Project Management Committee) have voted
>> to retire Shale and move the responsibility for its oversight over to
>> the Attic project.
>>
>> The MyFaces community has expressed interest in continuing development
>> of the Shale-Test module and the Shale PMC will work with MyFaces to
>> migrate this piece of the codebase.. Look for further announcements to
>> that regard in the near future.
>>
>> You can read more about the Apache Attic at http://attic.apache.org.
>>
>> You can follow the progress of the move at
>>
>>https://issues.apache.org/jira/browse/ATTIC-2 if you so wish.
>>
>> On behalf of the Apache Shale PMC, Thanks!
>>
>> Greg Reddin
>>
>>
>
> --
> Cyril Bouteille
> VP, Engineering
> TravelMuse, Inc.
>
>

Re: [ANNOUNCE] Apache Shale To Move To the Attic

[Greg Reddin]

On Tue, Apr 28, 2009 at 11:44 AM, Cyril Bouteille  wrote:
> This is sad news! Can you please recommend alternative projects for
> migration of deployed View-Controller and Remote features? Thanks.

Just my viewpoint: probably your best bet would be to migrate to Seam
and/or ajax4jsf.

But if you just don't feel like leaving Shale... This doesn't mean the
code is going to disappear. The code will be housed in the Apache
Attic svn. I'm not sure about existing releases, but I doubt they will
be removed from Maven repos, etc. If you feel like the code needs
further improvement feel free to start it back up at Google Code or
elsewhere. The only caveat to forking is that ASF still holds the
Apache Shale trademark so you'd have to come up with a different name.

Thanks,
Greg

Re: [ANNOUNCE] Apache Shale To Move To the Attic

[Cyril Bouteille]

This is sad news! Can you please recommend alternative projects for 
migration of deployed View-Controller and Remote features? Thanks.


Greg Reddin wrote:

This is a heads up for the Shale user community that the Shale PMC has
voted to move the project to the Attic. This means that the Shale
developers (more formally its Project Management Committee) have voted
to retire Shale and move the responsibility for its oversight over to
the Attic project.

The MyFaces community has expressed interest in continuing development
of the Shale-Test module and the Shale PMC will work with MyFaces to
migrate this piece of the codebase.. Look for further announcements to
that regard in the near future.

You can read more about the Apache Attic at http://attic.apache.org.

You can follow the progress of the move at

https://issues.apache.org/jira/browse/ATTIC-2 if you so wish.

On behalf of the Apache Shale PMC, Thanks!

Greg Reddin
  


--
Cyril Bouteille
VP, Engineering
TravelMuse, Inc.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Clay state question

[Gary%20VanMatre]

Hi Ryan, 

The primary reason was to lock down what made up the sub component tree after 
it was built the first time. This component builds all its children the first 
rendering. For state management reasons, you have to make sure that the 
component has the same shape on postback. This is especially important when it 
is in a UIData family of component where there is only one instance of the 
component and the model is enumerated underneath. We would need to store the 
subtrees off in a private facet if we wanted to start supporting polymorphic 
subtrees. The displayElementObject should be the same instance in memory that 
the TemplateConfigBean uses. 

Are you guys still using Clay or are you starting to migrate to Facets? 

Gary 

- Original Message - 
From: "Ryan Wynn"  
To: user@shale.apache.org 
Sent: Monday, March 16, 2009 3:25:38 PM GMT -07:00 US/Canada Mountain 
Subject: Clay state question 

I noticed that the Clay component saves the displayElementObject state in 
saveState. It would seem to me that this would cause some unnecessary 
overhead in terms of space when using server side state management. Since 
the displayElement root is already being cached globally in the 
TemplateConfigBean, would it be a valid optimization to have the Clay 
component retrieve it from there instead of "caching" it as part of the 
component state? 

Is there any reason why this needs to be saved as component state? 

Thanks, 
Ryan 

RE: Shale and AJAX4JSF issue

[Shridhar N S]

Hi Rahul,

Thank you for your reply.

I got the source for 1.0.5 and built it as mentioned in that bug. But we don't 
use facelets, so I couldn't use FaceletViewHandler. However, I tried making all 
the other changes mentioned in the bug. After those changes, I could get the 
a4j working. But when I have any a4j action tags like a4j:commandButton etc, I 
need to surround it with a4j:region. This breaks the ability of partial 
refreshing of the page, instead it refreshed the whole page. I also posted the 
question on a4j forum:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208054#4208054

Any further help is very much appreciated.

Thanks,
Shridhar

-Original Message-
From: Rahul Akolkar [mailto:rahul.akol...@gmail.com]
Sent: Sunday, February 08, 2009 9:04 PM
To: user@shale.apache.org
Subject: Re: Shale and AJAX4JSF issue

On Fri, Feb 6, 2009 at 8:28 PM, Shridhar N S  wrote:
> Hi,
>
> I am seeing the exact issue mentioned in:
> https://issues.apache.org/struts/browse/SHALE-409
>
> From the thread I am not clear, if the solution really works while using A4J 
> and Shale. Do we have a stable build for Shale that addresses this issue?
>


Fix version says v1.0.5, which is available here:

  http://www.apache.org/dyn/closer.cgi/shale/

I don't believe we have or intend to vote on v1.0.5 quality any time
soon, but you can try that if you want.

-Rahul


> Regards,
> Shridhar N S
> Sr.Web Engineer.
> TravelMuse, Inc.
> 4410 El Camino Real, Suite 102
> Los Altos, CA 94022
> Site: http://www.travelmuse.com<http://www.travelmuse.com/> 
> (RSS<http://www.travelmuse.com/rss>)
> Blogs: 
> Company<http://www.travelmuse.com/community/blogs/travelmuse-company-blog> 
> (RSS<http://www.travelmuse.com/community/blogs/travelmuse-company-blog/feeds/posts>)
>  | TravelMusings<http://www.travelmuse.com/community/blogs/travel_musings> 
> (RSS<http://www.travelmuse.com/community/blogs/travel_musings/feeds/posts>) | 
> Photo<http://www.travelmuse.com/community/blogs/photography> 
> (RSS<http://www.travelmuse.com/community/blogs/photography/feeds/posts>)
> Facebook: 
> Page<http://www.new.facebook.com/pages/Los-Altos-CA/TravelMuse/12711960515?ref=ts>
>  | App<http://apps.facebook.com/travelmuse/>
> 
> The information transmitted is intended only for the person or entity to 
> which it is addressed and may contain confidential and/or privileged 
> material. Any review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you received 
> this in error, please contact the sender and delete the material from any 
> computer.
>
>

Re: Shale and AJAX4JSF issue

[Rahul Akolkar]

On Fri, Feb 6, 2009 at 8:28 PM, Shridhar N S  wrote:
> Hi,
>
> I am seeing the exact issue mentioned in:
> https://issues.apache.org/struts/browse/SHALE-409
>
> From the thread I am not clear, if the solution really works while using A4J 
> and Shale. Do we have a stable build for Shale that addresses this issue?
>


Fix version says v1.0.5, which is available here:

  http://www.apache.org/dyn/closer.cgi/shale/

I don't believe we have or intend to vote on v1.0.5 quality any time
soon, but you can try that if you want.

-Rahul


> Regards,
> Shridhar N S
> Sr.Web Engineer.
> TravelMuse, Inc.
> 4410 El Camino Real, Suite 102
> Los Altos, CA 94022
> Site: http://www.travelmuse.com 
> (RSS)
> Blogs: 
> Company 
> (RSS)
>  | TravelMusings 
> (RSS) | 
> Photo 
> (RSS)
> Facebook: 
> Page
>  | App
> 
> The information transmitted is intended only for the person or entity to 
> which it is addressed and may contain confidential and/or privileged 
> material. Any review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you received 
> this in error, please contact the sender and delete the material from any 
> computer.
>
>

Re: shale-test and JMock2

[Matthias Wessendorf]

not yet:

https://issues.apache.org/struts/browse/SHALE-484

but this is actually already scheduled.
Stay tuned.

-M

On Mon, Oct 6, 2008 at 7:59 PM, Rogerio Pereira
<[EMAIL PROTECTED]> wrote:
> Is shale-test ready to use with JMock2?
>
> --
> Regards,
>
> Rogério (_rogerio_)
>
> [Blog: http://faces.eti.br]  [Sandbox: http://bmobile.dyndns.org]  [Twitter:
> http://twitter.com/ararog]
>
> "Faça a diferença! Ajude o seu país a crescer, não retenha conhecimento,
> distribua e aprenda mais."
> (http://faces.eti.br/2006/10/30/conhecimento-e-amadurecimento)
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [Test] outstanding patches ?

[Matthias Wessendorf]

no patches on TEST, that need to be committed ?

-M

On Wed, Oct 1, 2008 at 6:06 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Hi,
>
> are there outstanding patches ?
> If so, please reply to this mail with the according jira #.
>
> I will find some time for
> a) review
> b) applying them to Shale test.
>
> After that, I will find some more time to finally do a release (more
> on that later),
> first, let's get the patches in ;-)
>
> -M
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [ANNOUNCEMENT] New Shale Committer: Paul Spencer

[James Mitchell]

Welcome aboard!!!



On Thu, Oct 2, 2008 at 11:31 PM, Gary VanMatre <[EMAIL PROTECTED]> wrote:
> Please join me in welcoming Paul Spencer as the newest Shale committer.  Paul 
> has been very supportive of the Shale community over the past year.  Paul is 
> also a member of the MyFaces project.
>
> Welcome, Paul!
>
>



-- 
James Mitchell

Re: Tiger breaking my build

[Gary VanMatre]

From: Tyler Zale <[EMAIL PROTECTED]>
> Hi,
> 
> 
> I am having a problem with shale-tiger-1.0.5.
> 
> 
> Tiger is breaking my build because it is throwing a Digester error (no 
> grammar found).
> This is happening because I tried to add RichFaces to my project and the 
> faces-config.xml in the richfaces jars does not conform to Tiger's dtds.
> 
> I came up with a kludgish solution which consists of a combination of 
> altering the Tiger dtd and the faces-config.xml. But this solution bugs me.
> 
> I also tried using a context param (as I found listed in a jira entry: 
> http://issues.apache.org/struts/browse/SHALE-301):
> 
> 
> org.apache.shale.tiger.SCAN_PACKAGES
> com.x.y.z,shale-tiger-1.0.5.jar
> 
> 
> but this had a net effect of zero.
> 
> 
> Is there an easy way to stop shale-tiger from trying to read all the 
> jars in my lib and breaking?
> 
>

The SCAN_PACKAGES context param is only useful for specifying where to look for 
shale tiger annotations.  The lifecycle listener always tries to load the faces 
configs in /META-INF/faces-configs.xml.

I've not looked at RichFaces.  What have they added to the faces config that 
breaks the digester?Or, it might be that rich faces uses a JSF 1.2 DTD?  
Tiger only supports 1.0 and 1.1.

One thing that you might try is overriding the DTD's with one to support rich 
faces. The digest loads the DTD from the classpath.  You might try creating the 
same packages in your project and overriding.

"/org/apache/shale/tiger/resources/web-facesconfig_1_1.dtd"
"/org/apache/shale/tiger/resources/web-facesconfig_1_0.dtd"

 
 
> 
> Thanks,
> TZ


Gary

Re: org.apache.shale.dialog.basic.config.DialogImpl not serializable

[Rahul Akolkar]

On Wed, Jul 23, 2008 at 9:23 AM,  <[EMAIL PROTECTED]> wrote:

>
> Rahul, I debugged and this is my conclusion:
> org.apache.shale.dialog.faces.DialogPhaseListener in
> beforeRenderResponse put in the ViewRoot the
> "org.apache.shale.dialog.OPAQUE_STATE" attribute. The value of this
> attribute is, in my case, a class of BasicDialogContext$TopState and
> there is a reference to DialogImpl (BasicDialoContext has a property
> dialog and TopState is an inner class of BasicDialoContext).
>


Makes sense.


> So I think that the solution could be modify DialogImpl to implement
> Serializable?


Not really, I think TopState should rather be a static nested class (I
don't see any reason for it to be an inner class, the way things are
at the moment). Can you try making that change and testing your app?

Interim, you could choose a different dialog state storage strategy,
such as "stack" (see very bottom of this page [1]), and that should
remedy this as well.

Please open an issue in JIRA (and try the suggestions above if you can).

-Rahul

[1] http://shale.apache.org/shale-dialog-basic/



> If you agree, I'll track to JIRA also the solution...
>
> Please let me know what you think.
>
> Regards
> Mario
>
>

RE: org.apache.shale.dialog.basic.config.DialogImpl not serializable

[mario.buonopane]

From: Rahul Akolkar [mailto:[EMAIL PROTECTED] 
Sent: 22 luglio 2008 14.24
To: user@shale.apache.org; [EMAIL PROTECTED]
Subject: Re: org.apache.shale.dialog.basic.config.DialogImpl not
serializable

On Tue, Jul 22, 2008 at 2:45 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> Rahul, before track it to JIRA, i would like to understand why
> DilogImpl object is present in my HttpSession. At the moment i'm not
> sure if Shale is putting this object in the View root or other
> component is doing it.


Shale only puts the dialog ID (a String) as a view root attribute.

My initial thought was that the DialogImpl reference in the session
may come via BasicDialogContextManager -> BasicDialogContext ->
DialogImpl. I went back and looked at the code a bit, and it seems
that the DialogImpl is a transient reference and will be regenerated
as needed (therefore shouldn't cause the serialization issue). So:

 * Are you using vanilla Shale dialogs?
 * Are there other components that you have introduced that work with
Dialogs?
 * Do you have a smallest possible test case (one that uses the basic
impl as-is)?

-Rahul


> So, if you know that Shale could put an
> DilogImpl object in View root or in HttpSession please let me know. In
> this case i'll track to JIRA attaching the patch.
>
> Regards
> Mario
>

Rahul, I debugged and this is my conclusion:
org.apache.shale.dialog.faces.DialogPhaseListener in
beforeRenderResponse put in the ViewRoot the
"org.apache.shale.dialog.OPAQUE_STATE" attribute. The value of this
attribute is, in my case, a class of BasicDialogContext$TopState and
there is a reference to DialogImpl (BasicDialoContext has a property
dialog and TopState is an inner class of BasicDialoContext).

So I think that the solution could be modify DialogImpl to implement
Serializable?
If you agree, I'll track to JIRA also the solution...

Please let me know what you think.

Regards
Mario 





This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

Re: org.apache.shale.dialog.basic.config.DialogImpl not serializable

[Rahul Akolkar]

On Tue, Jul 22, 2008 at 2:45 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Rahul, before track it to JIRA, i would like to understand why
> DilogImpl object is present in my HttpSession. At the moment i'm not
> sure if Shale is putting this object in the View root or other
> component is doing it.


Shale only puts the dialog ID (a String) as a view root attribute.

My initial thought was that the DialogImpl reference in the session
may come via BasicDialogContextManager -> BasicDialogContext ->
DialogImpl. I went back and looked at the code a bit, and it seems
that the DialogImpl is a transient reference and will be regenerated
as needed (therefore shouldn't cause the serialization issue). So:

 * Are you using vanilla Shale dialogs?
 * Are there other components that you have introduced that work with Dialogs?
 * Do you have a smallest possible test case (one that uses the basic
impl as-is)?

-Rahul


> So, if you know that Shale could put an
> DilogImpl object in View root or in HttpSession please let me know. In
> this case i'll track to JIRA attaching the patch.
>
> Regards
> Mario
>

Re: org.apache.shale.dialog.basic.config.DialogImpl not serializable

[[EMAIL PROTECTED]]

Rahul, before track it to JIRA, i would like to understand why 
DilogImpl object is present in my HttpSession. At the moment i'm not 
sure if Shale is putting this object in the View root or other 
component is doing it. So, if you know that Shale could put an 
DilogImpl object in View root or in HttpSession please let me know. In 
this case i'll track to JIRA attaching the patch.

Regards
Mario



_
Tiscali Family: Adsl e Telefono senza limiti e senza scatto alla risposta. PER 
TE CON IL 25% DI SCONTO FINO AL 2010! Attiva entro il 24/07/08. 
http://abbonati.tiscali.it/promo/tuttoincluso/ 

Re: org.apache.shale.dialog.basic.config.DialogImpl not serializable

[Rahul Akolkar]

On Fri, Jul 18, 2008 at 8:40 AM, Mario Buonopane <[EMAIL PROTECTED]> wrote:
> Hi, I'm trying to serialize my HttpSession but I receive an error because
> org.apache.shale.dialog.basic.config.DialogImpl is not Serializable.
>


I cannot talk to the original intent, but I do think it makes sense to
have most bits in the config package above be Serializable.


> I think Shale is putting an object of this class in the view...
>
> Can you help me please?
>


If you want to track this, you could open an improvement request in
JIRA [1]. Further, if you want to help (which will increase the
chances that the JIRA issue will be looked at sooner), you could
attach a patch as well (see link to the "Apache Contributors Guide").

-Rahul

[1] http://shale.apache.org/issue-tracking.html


> Thanks in advance
> Mario
>
>

Re: Where is Shale1.1.0?

[Mario Buonopane]

Gary VanMatre ha scritto:

 -- Original message --
From: Paul Spencer <[EMAIL PROTECTED]>
  

Gary VanMatre wrote:


-- Original message -- From: Paul
Spencer <[EMAIL PROTECTED]>
  

Greg, My understanding is Shale v1.0.x and v1.1.x works with JSF
1.x.  Their may be components that are JSF version specific, but
this is the exception.



I agree but the shale test library for 1.1.x supports JSF 1.2 mock
objects which means it has Java 1.5 & JSF 1.2 dependencies.  The rest
of the libraries are still JSF 1.1 based.


  
So SHALE-262 - "Provide optional support for parsing faces-config.xml 
files in the classpath at startup time" will need to be backported to 
1.0.x to test a JSF 1.1 application, like Tomahawk?


Are their other alternatives the backporting?




Humm, it looks like the shale test pom has a 1.4 profile that excludes the JSF 1.2 objects.  The 1.1 trunk has the same type of profile.  Unless I'm mistaken, we would need two deployments for JSF 1.1 and 1.2.  



  

Paul Spencer





Gary 



  

I have a zip with a snapshot shale version 1.1.

Are you interested? If you want i can send you!

Ciao
Mario

Re: Can shale remoting use in web application without JSF?

[Wendy Smoak]

On Wed, Jul 16, 2008 at 3:37 PM, Gary VanMatre <[EMAIL PROTECTED]> wrote:

> True, but it's still built on and has dependencies with the JSF API's.  We 
> just provide mock implementations.

I'm thinking of CargoTestSetup, which has no JSF dependencies at all.
I've used it to test Struts apps, for example.

-- 
Wendy

Re: Can shale remoting use in web application without JSF?

[Gary VanMatre]

From: "Wendy Smoak" <[EMAIL PROTECTED]>
> On Wed, Jul 16, 2008 at 2:39 PM, Gary VanMatre <[EMAIL PROTECTED]> wrote:
> 
> > The shale remoting library is a value add for JSF and assumes JSF.  That's 
> true for all shale libraries.
> 
> ... except bits of Shale Test, which can be used without JSF.
>

True, but it's still built on and has dependencies with the JSF API's.  We just 
provide mock implementations.
 
> -- 
> Wendy

Re: Can shale remoting use in web application without JSF?

[Wendy Smoak]

On Wed, Jul 16, 2008 at 2:39 PM, Gary VanMatre <[EMAIL PROTECTED]> wrote:

> The shale remoting library is a value add for JSF and assumes JSF.  That's 
> true for all shale libraries.

... except bits of Shale Test, which can be used without JSF.

-- 
Wendy

Re: Can shale remoting use in web application without JSF?

[Gary VanMatre]

 -- Original message --
From: "Eric Chow" <[EMAIL PROTECTED]>
> Hello,
> 
> Can Shalre-Remoting load static javascript from JAR without using JSF?
> 
> If it can, can you show me a simple example?

The shale remoting library is a value add for JSF and assumes JSF.  That's true 
for all shale libraries.


> 
> Best regards,
> Eric

Gary

Re: Help with tld2claycfg for ajaxanywhere 1.2.1

[Tyler Zale]

Sorry for not being more clear.

I have already added ajaxanywhere as a dependancy:

   
 org.ajaxanywhere
 ajaxanywhere
 1.2.1
   

And installed it into maven.

Then when I run tld2claycfg it finds the tld (because if I change the 
path it whines that it cannot find it) but the entire output is still 
just "".


I am having a hard time understanding what I am doing wrong because the 
app runs without errors but still outputs blank. Is there any reason why 
it would not translate the ajaxanywhere tld?



Tyler


Gary VanMatre wrote:

 -- Original message --
From: Tyler Zale <[EMAIL PROTECTED]>
  

Hi,


I have been trying to integrate ajaxanywhere 1.2.1 with shale using clay 
html views.
As I understand it so far, the only way to achieve this is to have clay 
components defined (I am unaware of a simple include taglib directive in 
html views).


So I downloaded tld2claycfg from the svn and got it working (converted 
tomahawk 1.1.6 ok) but the clay config that gets generated for 
ajaxanywhere is blank (just results in: ).

I know it is finding the dependency.

Here is the tld section from the pom.xml in the 
"\maven\trunk\tld2claycfg\test\target\classes\META-INF" folder:



  META-INF/tlds/ajaxanywhere.tld
  1.2.1

  
(?i).*Listener.*,(?i).*Validate.*,(?i).*Convert.*
  
(?i).*Listener.*,(?i).*Validate.*,(?i).*Convert.*




  META-INF/tomahawk.tld
  1.1.6

  
(?i).*Listener.*,(?i).*Validate.*,(?i).*Convert.*
  
(?i).*Listener.*,(?i).*Validate.*,(?i).*Convert.*




Can someone let me know if I am on the right track or going about this 
completely the wrong way?





I think that this plugin looks at jar pom/file dependencies in the the class path.  Try add the ajaxanywhere dependency to your pom.  



  

Also, I have no idea about the mb/ac Filters, can anyone enlighten me?




The list of MB regular expressions are used to determine what tag attributes are value bindings versus method binding.  The clay xml config has an attribute that is used to determine what type of binding expression it is.  


I'm not sure what the heck the ac filter is used for.  You can see some 
examples here (clay-config.xml, tomahawk-1_1_3-config.xml):

http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/resources/META-INF/





  

Thanks,
TZ



Gary


  

Re: Help with tld2claycfg for ajaxanywhere 1.2.1

[Gary VanMatre]

 -- Original message --
From: Tyler Zale <[EMAIL PROTECTED]>
> Hi,
> 
> 
> I have been trying to integrate ajaxanywhere 1.2.1 with shale using clay 
> html views.
> As I understand it so far, the only way to achieve this is to have clay 
> components defined (I am unaware of a simple include taglib directive in 
> html views).
> 
> So I downloaded tld2claycfg from the svn and got it working (converted 
> tomahawk 1.1.6 ok) but the clay config that gets generated for 
> ajaxanywhere is blank (just results in: ).
> I know it is finding the dependency.
> 
> Here is the tld section from the pom.xml in the 
> "\maven\trunk\tld2claycfg\test\target\classes\META-INF" folder:
> 
> 
>   META-INF/tlds/ajaxanywhere.tld
>   1.2.1
> 
>   
> (?i).*Listener.*,(?i).*Validate.*,(?i).*Convert.*
>   
> (?i).*Listener.*,(?i).*Validate.*,(?i).*Convert.*
> 
> 
> 
>   META-INF/tomahawk.tld
>   1.1.6
> 
>   
> (?i).*Listener.*,(?i).*Validate.*,(?i).*Convert.*
>   
> (?i).*Listener.*,(?i).*Validate.*,(?i).*Convert.*
> 
> 
> 
> Can someone let me know if I am on the right track or going about this 
> completely the wrong way?
> 

I think that this plugin looks at jar pom/file dependencies in the the class 
path.  Try add the ajaxanywhere dependency to your pom.  


> Also, I have no idea about the mb/ac Filters, can anyone enlighten me?
> 

The list of MB regular expressions are used to determine what tag attributes 
are value bindings versus method binding.  The clay xml config has an attribute 
that is used to determine what type of binding expression it is.  

I'm not sure what the heck the ac filter is used for.  You can see some 
examples here (clay-config.xml, tomahawk-1_1_3-config.xml):

http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/resources/META-INF/





> 
> Thanks,
> TZ

Gary

Re: Use of Classifiers for Shale 1.1.0 (was Re: Where is Shale1.1.0?)

[Paul Spencer]

Gary VanMatre wrote:

-- Original message -- From: Paul
Spencer <[EMAIL PROTECTED]>

Gary VanMatre wrote:





 Spencer <[EMAIL PROTECTED]>
Humm, it looks like the shale test pom has a 1.4 profile that 
excludes the JSF 1.2 objects.  The 1.1 trunk has the same type of

 profile.  Unless I'm mistaken, we would need two deployments for
JSF 1.1 and 1.2.



Is this what "classifiers" are for?

I see their is are profiles for jdk 1.4, 1.5, and 1.6.  1.4 is for
 Servlet v 2.4 where as 1.5 and 1.6 are for Servlet v2.5.  Based on
this I see 2 distributions, one for JSF 1.1 (profile =
shale-test-jdk14) and one for JSF 1.2 ( profile = shale-test-jdk15)




Yeah, sounds like that's the ticket but it's the first I've heard of
classifiers.  Maybe one of our maven mavens could give some pointers
on how to configure a dual deployment.  Do you think we would need
two maven projects?

Any other apache projects doing this that we could borrow snippets?




I have asked a related question on the Maven user list with the subject 
"Are classifiers the answer, are they mature, what are the pitfalls?"[1] 
   As to other project using classifiers, I do not know :(





Paul Spencer


Gary



Paul Spencer






[1] http://markmail.org/message/l6v3nbnb6qwrdduy

Re: Use of Classifiers for Shale 1.1.0 (was Re: Where is Shale1.1.0?)

[Greg Reddin]

On Tue, Jun 10, 2008 at 9:18 AM, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
>>
>> I see their is are profiles for jdk 1.4, 1.5, and 1.6.  1.4 is for
>> Servlet v 2.4 where as 1.5 and 1.6 are for Servlet v2.5.  Based on this
>> I see 2 distributions, one for JSF 1.1 (profile = shale-test-jdk14) and
>> one for JSF 1.2 ( profile = shale-test-jdk15)
>>
>
> Yeah, sounds like that's the ticket but it's the first I've heard of 
> classifiers.  Maybe one of our maven mavens could give some pointers on how 
> to configure a dual deployment.  Do you think we would need two maven 
> projects?
>
> Any other apache projects doing this that we could borrow snippets?

I would think profiles would do everything we need. Is there a maven
thing called a "classifier" that goes beyond profiles (i.e. combining
profiles or something)?

Greg

Re: Use of Classifiers for Shale 1.1.0 (was Re: Where is Shale1.1.0?)

[Gary VanMatre]

 -- Original message --
From: Paul Spencer <[EMAIL PROTECTED]>
> Gary VanMatre wrote:
> > -- Original message -- From: Paul
> > Spencer <[EMAIL PROTECTED]>
> >> Gary VanMatre wrote:
> >>> -- Original message -- From: Paul
> >>>  Spencer <[EMAIL PROTECTED]>
>  Greg, My understanding is Shale v1.0.x and v1.1.x works with
>  JSF 1.x.  Their may be components that are JSF version
>  specific, but this is the exception.
>  
> >>> I agree but the shale test library for 1.1.x supports JSF 1.2
> >>> mock objects which means it has Java 1.5 & JSF 1.2 dependencies.
> >>> The rest of the libraries are still JSF 1.1 based.
> >>> 
> >>> 
> >> So SHALE-262 - "Provide optional support for parsing
> >> faces-config.xml files in the classpath at startup time" will need
> >> to be backported to 1.0.x to test a JSF 1.1 application, like
> >> Tomahawk?
> >> 
> >> Are their other alternatives the backporting?
> >> 
> > 
> > Humm, it looks like the shale test pom has a 1.4 profile that
> > excludes the JSF 1.2 objects.  The 1.1 trunk has the same type of
> > profile.  Unless I'm mistaken, we would need two deployments for JSF
> > 1.1 and 1.2.
> > 
> >
> 
> Is this what "classifiers" are for?
> 
> I see their is are profiles for jdk 1.4, 1.5, and 1.6.  1.4 is for 
> Servlet v 2.4 where as 1.5 and 1.6 are for Servlet v2.5.  Based on this 
> I see 2 distributions, one for JSF 1.1 (profile = shale-test-jdk14) and 
> one for JSF 1.2 ( profile = shale-test-jdk15)
> 

Yeah, sounds like that's the ticket but it's the first I've heard of 
classifiers.  Maybe one of our maven mavens could give some pointers on how to 
configure a dual deployment.  Do you think we would need two maven projects?

Any other apache projects doing this that we could borrow snippets?



> >> Paul Spencer
> >> 
> > 
> > Gary
> > 
> > 
> Paul Spencer

Use of Classifiers for Shale 1.1.0 (was Re: Where is Shale1.1.0?)

[Paul Spencer]

Gary VanMatre wrote:

-- Original message -- From: Paul
Spencer <[EMAIL PROTECTED]>

Gary VanMatre wrote:

-- Original message -- From: Paul
 Spencer <[EMAIL PROTECTED]>

Greg, My understanding is Shale v1.0.x and v1.1.x works with
JSF 1.x.  Their may be components that are JSF version
specific, but this is the exception.


I agree but the shale test library for 1.1.x supports JSF 1.2
mock objects which means it has Java 1.5 & JSF 1.2 dependencies.
The rest of the libraries are still JSF 1.1 based.



So SHALE-262 - "Provide optional support for parsing
faces-config.xml files in the classpath at startup time" will need
to be backported to 1.0.x to test a JSF 1.1 application, like
Tomahawk?

Are their other alternatives the backporting?



Humm, it looks like the shale test pom has a 1.4 profile that
excludes the JSF 1.2 objects.  The 1.1 trunk has the same type of
profile.  Unless I'm mistaken, we would need two deployments for JSF
1.1 and 1.2.




Is this what "classifiers" are for?

I see their is are profiles for jdk 1.4, 1.5, and 1.6.  1.4 is for 
Servlet v 2.4 where as 1.5 and 1.6 are for Servlet v2.5.  Based on this 
I see 2 distributions, one for JSF 1.1 (profile = shale-test-jdk14) and 
one for JSF 1.2 ( profile = shale-test-jdk15)



Paul Spencer



Gary



Paul Spencer

Re: Where is Shale1.1.0?

[Gary VanMatre]

 -- Original message --
From: Paul Spencer <[EMAIL PROTECTED]>
> Gary VanMatre wrote:
> > -- Original message -- From: Paul
> > Spencer <[EMAIL PROTECTED]>
> >> Greg, My understanding is Shale v1.0.x and v1.1.x works with JSF
> >> 1.x.  Their may be components that are JSF version specific, but
> >> this is the exception.
> >> 
> > 
> > I agree but the shale test library for 1.1.x supports JSF 1.2 mock
> > objects which means it has Java 1.5 & JSF 1.2 dependencies.  The rest
> > of the libraries are still JSF 1.1 based.
> > 
> > 
> 
> So SHALE-262 - "Provide optional support for parsing faces-config.xml 
> files in the classpath at startup time" will need to be backported to 
> 1.0.x to test a JSF 1.1 application, like Tomahawk?
> 
> Are their other alternatives the backporting?
> 

Humm, it looks like the shale test pom has a 1.4 profile that excludes the JSF 
1.2 objects.  The 1.1 trunk has the same type of profile.  Unless I'm mistaken, 
we would need two deployments for JSF 1.1 and 1.2.  


> 
> Paul Spencer
> 
>

Gary 

Re: Where is Shale1.1.0?

[Paul Spencer]

Gary VanMatre wrote:

-- Original message -- From: Paul
Spencer <[EMAIL PROTECTED]>

Greg, My understanding is Shale v1.0.x and v1.1.x works with JSF
1.x.  Their may be components that are JSF version specific, but
this is the exception.



I agree but the shale test library for 1.1.x supports JSF 1.2 mock
objects which means it has Java 1.5 & JSF 1.2 dependencies.  The rest
of the libraries are still JSF 1.1 based.




So SHALE-262 - "Provide optional support for parsing faces-config.xml 
files in the classpath at startup time" will need to be backported to 
1.0.x to test a JSF 1.1 application, like Tomahawk?


Are their other alternatives the backporting?


Paul Spencer

Re: Where is Shale1.1.0?

[Gary VanMatre]

 -- Original message --
From: Paul Spencer <[EMAIL PROTECTED]>
> Greg,
> My understanding is Shale v1.0.x and v1.1.x works with JSF 1.x.  Their 
> may be components that are JSF version specific, but this is the exception.
>

I agree but the shale test library for 1.1.x supports JSF 1.2 mock objects 
which means it has Java 1.5 & JSF 1.2 dependencies.  The rest of the libraries 
are still JSF 1.1 based.

 
> Paul Spencer
> 
> Greg Reddin wrote:
> > On Fri, Jun 6, 2008 at 2:49 AM, Mario Buonopane <[EMAIL PROTECTED]> wrote:
> >> No, i don't remember that Shale 1.1.0 is meant to be used with JSF 1.2 but
> >> with 1.1. In fact i'm using with MyFaces 1.5 (JSF 1.1).
> >> What does mean "GA" codebase?
> > 
> > I don't remember if JSF 1.2 is a requirement for Shale 1.1 or not.
> > ISTR us deciding we would target JSF 1.2 but I don't think that
> > introduces backwards incompatibility.
> > 
> > GA means General Availability - basically a production release. Shale
> > 1.0.4 is alpha quality because of dependencies on unreleased
> > libraries.
> > 
> > Greg
> > 
> 

Re: Where is Shale1.1.0?

[Paul Spencer]

Greg,
My understanding is Shale v1.0.x and v1.1.x works with JSF 1.x.  Their 
may be components that are JSF version specific, but this is the exception.


Paul Spencer

Greg Reddin wrote:

On Fri, Jun 6, 2008 at 2:49 AM, Mario Buonopane <[EMAIL PROTECTED]> wrote:

No, i don't remember that Shale 1.1.0 is meant to be used with JSF 1.2 but
with 1.1. In fact i'm using with MyFaces 1.5 (JSF 1.1).
What does mean "GA" codebase?


I don't remember if JSF 1.2 is a requirement for Shale 1.1 or not.
ISTR us deciding we would target JSF 1.2 but I don't think that
introduces backwards incompatibility.

GA means General Availability - basically a production release. Shale
1.0.4 is alpha quality because of dependencies on unreleased
libraries.

Greg

Re: Where is Shale1.1.0?

[Greg Reddin]

On Fri, Jun 6, 2008 at 2:49 AM, Mario Buonopane <[EMAIL PROTECTED]> wrote:
> No, i don't remember that Shale 1.1.0 is meant to be used with JSF 1.2 but
> with 1.1. In fact i'm using with MyFaces 1.5 (JSF 1.1).
> What does mean "GA" codebase?

I don't remember if JSF 1.2 is a requirement for Shale 1.1 or not.
ISTR us deciding we would target JSF 1.2 but I don't think that
introduces backwards incompatibility.

GA means General Availability - basically a production release. Shale
1.0.4 is alpha quality because of dependencies on unreleased
libraries.

Greg

Re: Where is Shale1.1.0?

[Mario Buonopane]

Greg Reddin ha scritto:

On Fri, May 30, 2008 at 12:20 PM, Mario Buonopane <[EMAIL PROTECTED]> wrote:
  

I don't understand why you are working now on version 1.0.5 and one year agò
on 1.1.0! If  you go in project summary you talk about version 1.1.0!



Mostly because (I think) 1.1.0 is meant to be used with JSF 1.2, etc.
and the 1.0 branch is designed to work with JSF 1.1. I have projects
that are currently using JSF 1.1 and I'd much rather be using a GA
codebase than a milestone build. Plus I'd really like to see Shale
release a GA codebase. It's been, what, 2 years? With the removal of
the Tiles dependency I think 1.0.5 could be GA. So my main goal is to
get a stable, relatively bug-free version of Shale out the door.

  
No, i don't remember that Shale 1.1.0 is meant to be used with JSF 1.2 
but with 1.1. In fact i'm using with MyFaces 1.5 (JSF 1.1).

What does mean "GA" codebase?

No, sorry but your response does not help me because at the moment i don't
know if 1.0.4 has same fix of my version. I remember that when i downloaded
a snapshot version was because the stable version didn't work well.
I don't know waht to do know...



If you can identify your bug I can let you know if it is fixed in
1.0.5. If not, well 1.0.5 is not released yet, so maybe we can
backport it. I'm working on the release now so let me know as quick as
you can.

Again, I'm sorry your experience has been what it is. In the future
you will see more Shale work from me than you have in the past. We'll
get there, but it will take time.

Greg

  

Re: Where is Shale1.1.0?

[Greg Reddin]

On Fri, May 30, 2008 at 12:20 PM, Mario Buonopane <[EMAIL PROTECTED]> wrote:
>
> I don't understand why you are working now on version 1.0.5 and one year agò
> on 1.1.0! If  you go in project summary you talk about version 1.1.0!

Mostly because (I think) 1.1.0 is meant to be used with JSF 1.2, etc.
and the 1.0 branch is designed to work with JSF 1.1. I have projects
that are currently using JSF 1.1 and I'd much rather be using a GA
codebase than a milestone build. Plus I'd really like to see Shale
release a GA codebase. It's been, what, 2 years? With the removal of
the Tiles dependency I think 1.0.5 could be GA. So my main goal is to
get a stable, relatively bug-free version of Shale out the door.

> No, sorry but your response does not help me because at the moment i don't
> know if 1.0.4 has same fix of my version. I remember that when i downloaded
> a snapshot version was because the stable version didn't work well.
> I don't know waht to do know...

If you can identify your bug I can let you know if it is fixed in
1.0.5. If not, well 1.0.5 is not released yet, so maybe we can
backport it. I'm working on the release now so let me know as quick as
you can.

Again, I'm sorry your experience has been what it is. In the future
you will see more Shale work from me than you have in the past. We'll
get there, but it will take time.

Greg

Re: Where is Shale1.1.0?

[Wendy Smoak]

On Fri, May 30, 2008 at 10:31 AM, Mario Buonopane <[EMAIL PROTECTED]> wrote:
> What happen to all fix listed here for version 1.1.0?
> https://issues.apache.org/struts/browse/SHALE/fixforversion/21780

All those fixes are committed to the 1.1.x trunk, which you can check
out of Subversion at this url:
http://svn.apache.org/repos/asf/shale/framework/trunk/

There's a bit more involved in building it (parent poms, snapshot
repositories) so as I mentioned, hop on the dev list if you'd like to
get more involved and help with it.

-- 
Wendy

Re: Where is Shale1.1.0?

[Wendy Smoak]

On Fri, May 30, 2008 at 10:20 AM, Mario Buonopane <[EMAIL PROTECTED]> wrote:

> I don't understand why you are working now on version 1.0.5 and one year agò
> on 1.1.0! If  you go in project summary you talk about version 1.1.0!

Because 1.0.x _also_ has fixes that people need and have been waiting
for a while, and there aren't a lot of people interested in working on
Shale right now.  Greg has decided to spend his volunteer time on a
1.0.5 release, first.

> No, sorry but your response does not help me because at the moment i don't
> know if 1.0.4 has same fix of my version. I remember that when i downloaded
> a snapshot version was because the stable version didn't work well.
> I don't know waht to do know...

Is there a JIRA issue for the fix you need?  If so it should have a
'fix-for' version and between the comments and the svn commit logs we
should be able to tell when and where (trunk or branch) it was fixed.

If you don't want to go digging in JIRA and Subversion, download the
latest release, and test it.  If it does not work for you, try a
snapshot of 1.0.5 and determine whether the fix is in there.

If that doesn't work, you can either wait for someone to work on the
1.1.x build, or check out the source code and see if you can help fix
it.

If you decide to try snapshots and/or building Shale yourself, please
come join us on the dev list.  See:
http://shale.apache.org/mail-lists.html

-- 
Wendy

Re: Where is Shale1.1.0?

[Mario Buonopane]

Mario Buonopane ha scritto:

Greg Reddin ha scritto:
On Fri, May 30, 2008 at 4:48 AM, Mario Buonopane <[EMAIL PROTECTED]> 
wrote:
 

Hi, one year agò i download the shale version 1.1.0-SNAPSHOT-20070626.
Now i can't find any version 1.1.X from the shale site. Any body cna 
help

me?



We're sort of in a state of disrepair right now. Do you know where you
downloaded it from? I can't find it in any of the usual places now. It
won't be in the nightly build area because the 1.1.0 branch won't
build.

  
I downloaded one year agò...i don't remember where (i suppose in 
nightly build) but i remember that  the first version after 1.0.4 was 
1.1.x.

If you want the latest release version you can download 1.0.4 here:

http://www.apache.org/dyn/closer.cgi/shale/

If you want something newer than that you can check out the source for
1.0.5 and build it (we're working on a 1.0.5 release). The svn
location for 1.0.5 is:

svn co 
http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/


If you really need 1.1.0 the news is not good right now. As soon as
the 1.0.5 release is done I'm planning to start looking at 1.1.0 and
getting it working. In the meantime you're welcome to check out the
source and give it a try yourself:

svn co http://svn.apache.org/repos/asf/shale/framework/trunk/

  
I don't understand why you are working now on version 1.0.5 and one 
year agò on 1.1.0! If  you go in project summary you talk about 
version 1.1.0!



Does that help? Sorry for the mess.
  
No, sorry but your response does not help me because at the moment i 
don't know if 1.0.4 has same fix of my version. I remember that when i 
downloaded a snapshot version was because the stable version didn't 
work well.

I don't know waht to do know...

Greg

  

Mario


What happen to all fix listed here for version 1.1.0?
https://issues.apache.org/struts/browse/SHALE/fixforversion/21780

M.

Re: Where is Shale1.1.0?

[Mario Buonopane]

Greg Reddin ha scritto:

On Fri, May 30, 2008 at 4:48 AM, Mario Buonopane <[EMAIL PROTECTED]> wrote:
  

Hi, one year agò i download the shale version 1.1.0-SNAPSHOT-20070626.
Now i can't find any version 1.1.X from the shale site. Any body cna help
me?



We're sort of in a state of disrepair right now. Do you know where you
downloaded it from? I can't find it in any of the usual places now. It
won't be in the nightly build area because the 1.1.0 branch won't
build.

  
I downloaded one year agò...i don't remember where (i suppose in nightly 
build) but i remember that  the first version after 1.0.4 was 1.1.x.

If you want the latest release version you can download 1.0.4 here:

http://www.apache.org/dyn/closer.cgi/shale/

If you want something newer than that you can check out the source for
1.0.5 and build it (we're working on a 1.0.5 release). The svn
location for 1.0.5 is:

svn co http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/

If you really need 1.1.0 the news is not good right now. As soon as
the 1.0.5 release is done I'm planning to start looking at 1.1.0 and
getting it working. In the meantime you're welcome to check out the
source and give it a try yourself:

svn co http://svn.apache.org/repos/asf/shale/framework/trunk/

  
I don't understand why you are working now on version 1.0.5 and one year 
agò on 1.1.0! If  you go in project summary you talk about version 1.1.0!



Does that help? Sorry for the mess.
  
No, sorry but your response does not help me because at the moment i 
don't know if 1.0.4 has same fix of my version. I remember that when i 
downloaded a snapshot version was because the stable version didn't work 
well.

I don't know waht to do know...

Greg

  

Mario

Re: Where is Shale1.1.0?

[Greg Reddin]

On Fri, May 30, 2008 at 4:48 AM, Mario Buonopane <[EMAIL PROTECTED]> wrote:
> Hi, one year agò i download the shale version 1.1.0-SNAPSHOT-20070626.
> Now i can't find any version 1.1.X from the shale site. Any body cna help
> me?

We're sort of in a state of disrepair right now. Do you know where you
downloaded it from? I can't find it in any of the usual places now. It
won't be in the nightly build area because the 1.1.0 branch won't
build.

If you want the latest release version you can download 1.0.4 here:

http://www.apache.org/dyn/closer.cgi/shale/

If you want something newer than that you can check out the source for
1.0.5 and build it (we're working on a 1.0.5 release). The svn
location for 1.0.5 is:

svn co http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/

If you really need 1.1.0 the news is not good right now. As soon as
the 1.0.5 release is done I'm planning to start looking at 1.1.0 and
getting it working. In the meantime you're welcome to check out the
source and give it a try yourself:

svn co http://svn.apache.org/repos/asf/shale/framework/trunk/

Does that help? Sorry for the mess.

Greg

Re: AbstractJsfTestCase question

[Venkataganesh Thoppae]

Fine. Understandable. Thanks.


On Tue, May 20, 2008 at 4:07 PM, Gary VanMatre <[EMAIL PROTECTED]>
wrote:

> The shale mock value binding has limited EL support.
>
> [] #parse -
> http://svn.apache.org/viewvc/shale/framework/trunk/shale-test/src/main/java/org/apache/shale/test/mock/MockValueBinding.java?view=markup
>  -- Original message --
> From: "Venkataganesh Thoppae" <[EMAIL PROTECTED]>
> > Actually I missed that part while typing a sample code.
> > But here is a clean test case runnable if you have shale-test-x.jar.
> > Appreciate if someone could try this on their box.
> >
> > Two files are attached.
> > MyTestCase.java has test cases defined.
> > SomeBean is a simple POJO.
> >
> > Thanks
> >
> > On Tue, May 20, 2008 at 10:57 AM, Chris Keefer <[EMAIL PROTECTED]> wrote:
> >
> > > I think in JSF 1.1 you have to get the value from a ValueBinding. See
> > > below.
> > >
> > > @Test
> > > public void test1 {
> > >ValueBinding binding =
> > >
> facesContext.getApplication().createValueBinding("#{someBean.prop[0]}"};
> > >String val = (String) binding.getValue(facesContext);
> > >assertEquals(val, "M");
> > > }
> > >
> > >
> > > Or you can try the VariableResolver like so:
> > >
> > > @Test
> > > public void test1 {
> > >String val =
> > >
> >
> facesContext.getApplication().getVariableResolver().resolveVariable(facesContext
> > ,
> > > "#{someBean.prop[0]}");
> > >assertEquals(val, "M");
> > > }
> > >
> > > Hope this helps.
> > >
> > > --Chris
> > >
> > >
> > >
> > >
> > > On May 19, 2008, at 1:06 PM, Venkataganesh Thoppae wrote:
> > >
> > >  Yes, I know Shale doesn't read faces-config.
> > >> Here is a sample implementation.
> > >>
> > >> public class MyTestCase extends AbstractJsfTestCase {
> > >> //A valid someBean object is created in the request scope in setUp()
> > >>
> > >> @Test
> > >> public void test1 {
> > >>String val=
> > >>
> > >>
> >
> (String)facesContext.getApplication().createValueBinding("#{someBean.prop[0]}"};
> > >>assertEquals(val, "M");
> > >> }
> > >> }
> > >>
> > >> The error I get is:
> > >> javax.faces.el.PropertyNotFoundException: prop0
> > >>at
> > >>
> > >>
> >
> org.apache.shale.test.mock.MockPropertyResolver.descriptor(MockPropertyResolver.
> > java:213)
> > >>at
> > >>
> > >>
> >
> org.apache.shale.test.mock.MockPropertyResolver.getValue(MockPropertyResolver.ja
> > va:69)
> > >>at
> > >>
> > >>
> >
> org.apache.shale.test.mock.MockValueBinding.getValue(MockValueBinding.java:126)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Regards
> > >>
> > >>
> > >>
> > >> On Mon, May 19, 2008 at 12:08 PM, Kito D. Mann <[EMAIL PROTECTED]>
> wrote:
> > >>
> > >>  Hmm... What errors are you getting? Or is it just returning null? If
> it's
> > >>> just returning null, remember that you must manually but the bean in
> the
> > >>> proper scope - Shale doesn't read faces-config.
> > >>>
> > >>> Sent from my iPhone
> > >>>
> > >>>
> > >>> On May 19, 2008, at 11:07 AM, "Venkataganesh Thoppae" <
> > >>> [EMAIL PROTECTED]>
> > >>> wrote:
> > >>>
> > >>>  New user of Shale Test framework. I'm trying to write some test
> cases
> > >>> for
> > >>>
> > >>>> JSF 1.1 implementation using AbstractJsfTestCase.
> > >>>>
> > >>>> Experiencing few problems while trying to resolve some EL
> expressions
> > >>>> programmatically.
> > >>>> - MockVariableResolver not able to resolve array elements like
> > >>>> #{someBean.property[0]}
> > >>>> - How would I resolve an expression like #{someBean.name == "John
> Doe"}
> > >>>> - How could I invoke static EL func

Re: AbstractJsfTestCase question

[Gary VanMatre]

The shale mock value binding has limited EL support.  

[] #parse - 
http://svn.apache.org/viewvc/shale/framework/trunk/shale-test/src/main/java/org/apache/shale/test/mock/MockValueBinding.java?view=markup
 -- Original message --
From: "Venkataganesh Thoppae" <[EMAIL PROTECTED]>
> Actually I missed that part while typing a sample code.
> But here is a clean test case runnable if you have shale-test-x.jar.
> Appreciate if someone could try this on their box.
> 
> Two files are attached.
> MyTestCase.java has test cases defined.
> SomeBean is a simple POJO.
> 
> Thanks
> 
> On Tue, May 20, 2008 at 10:57 AM, Chris Keefer <[EMAIL PROTECTED]> wrote:
> 
> > I think in JSF 1.1 you have to get the value from a ValueBinding. See
> > below.
> >
> > @Test
> > public void test1 {
> >ValueBinding binding =
> > facesContext.getApplication().createValueBinding("#{someBean.prop[0]}"};
> >String val = (String) binding.getValue(facesContext);
> >assertEquals(val, "M");
> > }
> >
> >
> > Or you can try the VariableResolver like so:
> >
> > @Test
> > public void test1 {
> >String val =
> > 
> facesContext.getApplication().getVariableResolver().resolveVariable(facesContext
> ,
> > "#{someBean.prop[0]}");
> >assertEquals(val, "M");
> > }
> >
> > Hope this helps.
> >
> > --Chris
> >
> >
> >
> >
> > On May 19, 2008, at 1:06 PM, Venkataganesh Thoppae wrote:
> >
> >  Yes, I know Shale doesn't read faces-config.
> >> Here is a sample implementation.
> >>
> >> public class MyTestCase extends AbstractJsfTestCase {
> >> //A valid someBean object is created in the request scope in setUp()
> >>
> >> @Test
> >> public void test1 {
> >>String val=
> >>
> >> 
> (String)facesContext.getApplication().createValueBinding("#{someBean.prop[0]}"};
> >>assertEquals(val, "M");
> >> }
> >> }
> >>
> >> The error I get is:
> >> javax.faces.el.PropertyNotFoundException: prop0
> >>at
> >>
> >> 
> org.apache.shale.test.mock.MockPropertyResolver.descriptor(MockPropertyResolver.
> java:213)
> >>at
> >>
> >> 
> org.apache.shale.test.mock.MockPropertyResolver.getValue(MockPropertyResolver.ja
> va:69)
> >>at
> >>
> >> 
> org.apache.shale.test.mock.MockValueBinding.getValue(MockValueBinding.java:126)
> >>
> >>
> >>
> >>
> >>
> >>
> >> Regards
> >>
> >>
> >>
> >> On Mon, May 19, 2008 at 12:08 PM, Kito D. Mann <[EMAIL PROTECTED]> wrote:
> >>
> >>  Hmm... What errors are you getting? Or is it just returning null? If it's
> >>> just returning null, remember that you must manually but the bean in the
> >>> proper scope - Shale doesn't read faces-config.
> >>>
> >>> Sent from my iPhone
> >>>
> >>>
> >>> On May 19, 2008, at 11:07 AM, "Venkataganesh Thoppae" <
> >>> [EMAIL PROTECTED]>
> >>> wrote:
> >>>
> >>>  New user of Shale Test framework. I'm trying to write some test cases
> >>> for
> >>>
>  JSF 1.1 implementation using AbstractJsfTestCase.
> 
>  Experiencing few problems while trying to resolve some EL expressions
>  programmatically.
>  - MockVariableResolver not able to resolve array elements like
>  #{someBean.property[0]}
>  - How would I resolve an expression like #{someBean.name == "John Doe"}
>  - How could I invoke static EL functions like #{prefix:fnName}
> 
>  Advance Thanks for your help.
> 
> 
> >>>
> >>
> >> --
> >>
> >
> >
> 
> 
> -- 
> Regards
> Venkat Thoppae
> (240)446-7632


--- Begin Message ---
Actually I missed that part while typing a sample code.
But here is a clean test case runnable if you have shale-test-x.jar.
Appreciate if someone could try this on their box.

Two files are attached.
MyTestCase.java has test cases defined.
SomeBean is a simple POJO.

Thanks

On Tue, May 20, 2008 at 10:57 AM, Chris Keefer <[EMAIL PROTECTED]> wrote:

> I think in JSF 1.1 you have to get the value from a ValueBinding. See
> below.
>
> @Test
> public void test1 {
>ValueBinding binding =
> facesContext.getApplication().createValueBinding("#{someBean.prop[0]}"};
>String val = (String) binding.getValue(facesContext);
>assertEquals(val, "M");
> }
>
>
> Or you can try the VariableResolver like so:
>
> @Test
> public void test1 {
>String val =
> facesContext.getApplication().getVariableResolver().resolveVariable(facesContext,
> "#{someBean.prop[0]}");
>assertEquals(val, "M");
> }
>
> Hope this helps.
>
> --Chris
>
>
>
>
> On May 19, 2008, at 1:06 PM, Venkataganesh Thoppae wrote:
>
>  Yes, I know Shale doesn't read faces-config.
>> Here is a sample implementation.
>>
>> public class MyTestCase extends AbstractJsfTestCase {
>> //A valid someBean object is created in the request scope in setUp()
>>
>> @Test
>> public void test1 {
>>String val=
>>
>> (String)facesContext.getApplication().createValueBinding("#{someBean.prop[0]}"};
>>assertEquals(val, "M");
>> }
>> }
>>
>> The error I get is:
>> javax.faces.el.PropertyNotFoundException: prop0
>>at
>>
>> org.apache.shale.test.mock.MockPropertyResolver.descriptor(MockPr

Re: AbstractJsfTestCase question

[Venkataganesh Thoppae]

Actually I missed that part while typing a sample code.
But here is a clean test case runnable if you have shale-test-x.jar.
Appreciate if someone could try this on their box.

Two files are attached.
MyTestCase.java has test cases defined.
SomeBean is a simple POJO.

Thanks

On Tue, May 20, 2008 at 10:57 AM, Chris Keefer <[EMAIL PROTECTED]> wrote:

> I think in JSF 1.1 you have to get the value from a ValueBinding. See
> below.
>
> @Test
> public void test1 {
>ValueBinding binding =
> facesContext.getApplication().createValueBinding("#{someBean.prop[0]}"};
>String val = (String) binding.getValue(facesContext);
>assertEquals(val, "M");
> }
>
>
> Or you can try the VariableResolver like so:
>
> @Test
> public void test1 {
>String val =
> facesContext.getApplication().getVariableResolver().resolveVariable(facesContext,
> "#{someBean.prop[0]}");
>assertEquals(val, "M");
> }
>
> Hope this helps.
>
> --Chris
>
>
>
>
> On May 19, 2008, at 1:06 PM, Venkataganesh Thoppae wrote:
>
>  Yes, I know Shale doesn't read faces-config.
>> Here is a sample implementation.
>>
>> public class MyTestCase extends AbstractJsfTestCase {
>> //A valid someBean object is created in the request scope in setUp()
>>
>> @Test
>> public void test1 {
>>String val=
>>
>> (String)facesContext.getApplication().createValueBinding("#{someBean.prop[0]}"};
>>assertEquals(val, "M");
>> }
>> }
>>
>> The error I get is:
>> javax.faces.el.PropertyNotFoundException: prop0
>>at
>>
>> org.apache.shale.test.mock.MockPropertyResolver.descriptor(MockPropertyResolver.java:213)
>>at
>>
>> org.apache.shale.test.mock.MockPropertyResolver.getValue(MockPropertyResolver.java:69)
>>at
>>
>> org.apache.shale.test.mock.MockValueBinding.getValue(MockValueBinding.java:126)
>>
>>
>>
>>
>>
>>
>> Regards
>>
>>
>>
>> On Mon, May 19, 2008 at 12:08 PM, Kito D. Mann <[EMAIL PROTECTED]> wrote:
>>
>>  Hmm... What errors are you getting? Or is it just returning null? If it's
>>> just returning null, remember that you must manually but the bean in the
>>> proper scope - Shale doesn't read faces-config.
>>>
>>> Sent from my iPhone
>>>
>>>
>>> On May 19, 2008, at 11:07 AM, "Venkataganesh Thoppae" <
>>> [EMAIL PROTECTED]>
>>> wrote:
>>>
>>>  New user of Shale Test framework. I'm trying to write some test cases
>>> for
>>>
 JSF 1.1 implementation using AbstractJsfTestCase.

 Experiencing few problems while trying to resolve some EL expressions
 programmatically.
 - MockVariableResolver not able to resolve array elements like
 #{someBean.property[0]}
 - How would I resolve an expression like #{someBean.name == "John Doe"}
 - How could I invoke static EL functions like #{prefix:fnName}

 Advance Thanks for your help.


>>>
>>
>> --
>>
>
>


-- 
Regards
Venkat Thoppae
(240)446-7632

Re: AbstractJsfTestCase question

[Chris Keefer]

I think in JSF 1.1 you have to get the value from a ValueBinding. See  
below.


@Test
public void test1 {
ValueBinding binding = facesContext.getApplication 
().createValueBinding("#{someBean.prop[0]}"};

String val = (String) binding.getValue(facesContext);
assertEquals(val, "M");
}


Or you can try the VariableResolver like so:

@Test
public void test1 {
String val = facesContext.getApplication().getVariableResolver 
().resolveVariable(facesContext, "#{someBean.prop[0]}");

assertEquals(val, "M");
}

Hope this helps.

--Chris



On May 19, 2008, at 1:06 PM, Venkataganesh Thoppae wrote:


Yes, I know Shale doesn't read faces-config.
Here is a sample implementation.

public class MyTestCase extends AbstractJsfTestCase {
//A valid someBean object is created in the request scope in setUp()

@Test
public void test1 {
String val=
(String)facesContext.getApplication().createValueBinding("# 
{someBean.prop[0]}"};

assertEquals(val, "M");
}
}

The error I get is:
javax.faces.el.PropertyNotFoundException: prop0
at
org.apache.shale.test.mock.MockPropertyResolver.descriptor 
(MockPropertyResolver.java:213)

at
org.apache.shale.test.mock.MockPropertyResolver.getValue 
(MockPropertyResolver.java:69)

at
org.apache.shale.test.mock.MockValueBinding.getValue 
(MockValueBinding.java:126)







Regards



On Mon, May 19, 2008 at 12:08 PM, Kito D. Mann <[EMAIL PROTECTED]>  
wrote:


Hmm... What errors are you getting? Or is it just returning null?  
If it's
just returning null, remember that you must manually but the bean  
in the

proper scope - Shale doesn't read faces-config.

Sent from my iPhone


On May 19, 2008, at 11:07 AM, "Venkataganesh Thoppae"  
<[EMAIL PROTECTED]>

wrote:

 New user of Shale Test framework. I'm trying to write some test  
cases for

JSF 1.1 implementation using AbstractJsfTestCase.

Experiencing few problems while trying to resolve some EL  
expressions

programmatically.
- MockVariableResolver not able to resolve array elements like
#{someBean.property[0]}
- How would I resolve an expression like #{someBean.name == "John  
Doe"}

- How could I invoke static EL functions like #{prefix:fnName}

Advance Thanks for your help.






--

RE: [Tomahawk] - Both MyFaces and the RI are on your classpath

[mario.buonopane]

I'm very sorryi'm going to send the message to MyFaces!

Thanks 
Mario 

-Original Message-
From: Greg Reddin [mailto:[EMAIL PROTECTED] 
Sent: 20 maggio 2008 15.49
To: user@shale.apache.org
Subject: Re: [Tomahawk] - Both MyFaces and the RI are on your classpath

On Tue, May 20, 2008 at 5:49 AM,  <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm using Tomahawk 1.1.6 on WebSphere 6.1 and does work correctly. But
> on the log I found:
> "Both MyFaces and the RI are on your classpath. Please make sure to
use
> only one of the two JSF-implementations."
> I know that WAS has a JSF 1.1 implementation (Sun implementation) and
my
> application classloader policy is PARENT-LAST. The question is:
> The log has an "ERROR" severity, so can this cause some problem?

You should probably redirect this to [EMAIL PROTECTED] for a
better response. I know I've seen that message before, but I'm not
sure what sort of problems it may indicate.

Thanks,
Greg



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

Re: [Tomahawk] - Both MyFaces and the RI are on your classpath

[Greg Reddin]

On Tue, May 20, 2008 at 5:49 AM,  <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm using Tomahawk 1.1.6 on WebSphere 6.1 and does work correctly. But
> on the log I found:
> "Both MyFaces and the RI are on your classpath. Please make sure to use
> only one of the two JSF-implementations."
> I know that WAS has a JSF 1.1 implementation (Sun implementation) and my
> application classloader policy is PARENT-LAST. The question is:
> The log has an "ERROR" severity, so can this cause some problem?

You should probably redirect this to [EMAIL PROTECTED] for a
better response. I know I've seen that message before, but I'm not
sure what sort of problems it may indicate.

Thanks,
Greg

Re: AbstractJsfTestCase question

[Venkataganesh Thoppae]

Yes, I know Shale doesn't read faces-config.
Here is a sample implementation.

public class MyTestCase extends AbstractJsfTestCase {
//A valid someBean object is created in the request scope in setUp()

@Test
public void test1 {
String val=
(String)facesContext.getApplication().createValueBinding("#{someBean.prop[0]}"};
assertEquals(val, "M");
}
}

The error I get is:
javax.faces.el.PropertyNotFoundException: prop0
at
org.apache.shale.test.mock.MockPropertyResolver.descriptor(MockPropertyResolver.java:213)
at
org.apache.shale.test.mock.MockPropertyResolver.getValue(MockPropertyResolver.java:69)
at
org.apache.shale.test.mock.MockValueBinding.getValue(MockValueBinding.java:126)






Regards



On Mon, May 19, 2008 at 12:08 PM, Kito D. Mann <[EMAIL PROTECTED]> wrote:

> Hmm... What errors are you getting? Or is it just returning null? If it's
> just returning null, remember that you must manually but the bean in the
> proper scope - Shale doesn't read faces-config.
>
> Sent from my iPhone
>
>
> On May 19, 2008, at 11:07 AM, "Venkataganesh Thoppae" <[EMAIL PROTECTED]>
> wrote:
>
>  New user of Shale Test framework. I'm trying to write some test cases for
>> JSF 1.1 implementation using AbstractJsfTestCase.
>>
>> Experiencing few problems while trying to resolve some EL expressions
>> programmatically.
>> - MockVariableResolver not able to resolve array elements like
>> #{someBean.property[0]}
>> - How would I resolve an expression like #{someBean.name == "John Doe"}
>> - How could I invoke static EL functions like #{prefix:fnName}
>>
>> Advance Thanks for your help.
>>
>


--

Re: AbstractJsfTestCase question

[Kito D. Mann]

Hmm... What errors are you getting? Or is it just returning null? If  
it's just returning null, remember that you must manually but the bean  
in the proper scope - Shale doesn't read faces-config.


Sent from my iPhone

On May 19, 2008, at 11:07 AM, "Venkataganesh Thoppae" <[EMAIL PROTECTED] 
> wrote:


New user of Shale Test framework. I'm trying to write some test  
cases for

JSF 1.1 implementation using AbstractJsfTestCase.

Experiencing few problems while trying to resolve some EL expressions
programmatically.
- MockVariableResolver not able to resolve array elements like
#{someBean.property[0]}
- How would I resolve an expression like #{someBean.name == "John  
Doe"}

- How could I invoke static EL functions like #{prefix:fnName}

Advance Thanks for your help.

Re: JSF 1.2 (MyFaces Core 1.2.x - implementation) & Struts Shale

[Costa Basil]

>I'm using JSF 1.2 Mojarra implementation w/ Shale just fine, but I 
>unfortunately can't speak to MyFaces compatibility.

That is good to know. 

Thanks



  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

Re: JSF 1.2 (MyFaces Core 1.2.x - implementation) & Struts Shale

[Cyril Bouteille]

JSF 1.2 introduced @PostConstruct and @PreDestroy annotations (see 
http://weblogs.java.net/blog/jhook/archive/2007/05/jsf_12_ri_backi.html), 
which somewhat overlap with Shale's prerender/destroy hooks, but it's 
still not quite as powerful. Most notably:
* @PostConstruct won't get call on every page it's used w/ a 
session-scoped FB, and
* you can't control @PostConstruct execution everytime the FB is 
instanciated as Shale allows you to w/  does.
I'm using JSF 1.2 Mojarra implementation w/ Shale just fine, but I 
unfortunately can't speak to MyFaces compatibility.


Costa Basil wrote:
I've been successfully using Struts Shale 1.0.3 with MyFaces 1.1.x & Tomhawk 1.1.x. Now I want to upgrade to MyFaces Core 1.2.x which is a JSF 1.2 implementation. Can someone please tell me if JSF 1.2 makes some of features in Struts Shale Core obsolete - for instance the ViewController mechanism? Will Struts Shale work with MyFaces 1.2 seamlessly? 


My code is relying heavily on the shale framework (core) - all my managed beans 
extend the AbstractViewController class and rely on the ViewController calls made 
by the framework to prerender, init & co. I am also using some of the 
validation tags.

I didn't dig up the JSF 1.2 documentation but I think I read somewhere that JSF 
1.2 offers something similar to the ViewController mechanism.

Thanks


  __
Connect with friends from any web browser - no download required. Try the new 
Yahoo! Canada Messenger for the Web BETA at 
http://ca.messenger.yahoo.com/webmessengerpromo.php
  


--
Cyril Bouteille
VP, Engineering

TravelMuse, Inc.
4410 El Camino Real, Suite 102
Los Altos, CA 94022
(f) 650-941-4751
http://www.travelmuse.com
[EMAIL PROTECTED] 

The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material. Any review, retransmission, dissemination or other use of, or 
taking of any action in reliance upon, this information by persons or 
entities other than the intended recipient is prohibited. If you 
received this in error, please contact the sender and delete the 
material from any computer.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Broken URL's

[Cristi Magherusan]

Hello,

Thanks for your answers! Well, the code itself is valid, but some IDEs
(in my case netbeans) use them to enable smart code completion and other
features for those tags. The problem is that the URI it needs
(http://shale.apache.org/core) is a 404 and I get no help from
netbeans. Also, I've found a few other broken links on the website that
would be nice to be fixed:

Only http://wiki.apache.org/shale/ShaleValidation references two broken
ones. 
I'll try Richard's tip and report any results.

Many thanks,
Cristi

Re: Broken URL's

[Wendy Smoak]

On Sun, May 11, 2008 at 5:00 PM, Cristi Magherusan
<[EMAIL PROTECTED]> wrote:

>  I'm having a school project that must use shale, but it seems its
>  taglibs uri's are broken links, among others. Please someone fix them,
>  if possible. Also, is there a way to use local files instead of http://
>  links?

Please describe the problem you're having, and I'm sure someone can
help you sort it out.  As others have mentioned a URI is an
identifier, there's no requirement that a taglib uri be a valid url.

If you use the correct URI (one that matches exactly with the one in
the tld inside the jar file) then your container should discover the
taglibs  automatically.  Specifically, you do *not* need to extract
them from the jar or put anything in web.xml, unless you are using a
very old Servlet container.  Ignore the Struts references, and see if
this helps:  http://wiki.wsmoak.net/cgi-bin/wiki.pl?WebXmlNoTaglib and
http://marc.info/?l=struts-user&m=104205482618830&w=2

>  Please use cc to send your answers to me since I'm not yet subscribed to
>  the shale Mailing List.

Just this once. :)  You can watch the list on one of the many archive
sites, like Nabble:  http://www.nabble.com/Shale---User-f15689.html

-- 
Wendy

RE: Broken URL's

[Richard Eggert]

You need to add something like this to your web.xml file:


   
  http://shale.apache.org/clay
  /WEB-INF/lib/shale-clay.jar
   



If that doesn't work (i.e., if the JSP engine can't find the tld file within 
the JAR file for some reason), pull the TLD file out of the JAR file, place it 
somewhere in your WEB-INF directory (perhaps in a subdirectory named "tld", for 
example), and put this in your web.xml instead:


   
  http://shale.apache.org/clay
  /WEB-INF/tld/shale-clay.tld
   


Note that if you are using more than one tag library, each tag library that you 
use needs its own  entry, and all  elements must be contained 
within a single  (the XML schema validator will reject it if you 
have more than one ).

As was already pointed out, the URI's are only unique names, and have no 
meaning in terms of where JSP looks for the definitions.


Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Cristi Magherusan [mailto:[EMAIL PROTECTED]
Sent: Sun 5/11/2008 8:00 PM
To: user@shale.apache.org
Subject: Broken URL's
 
Hello,

I'm having a school project that must use shale, but it seems its
taglibs uri's are broken links, among others. Please someone fix them,
if possible. Also, is there a way to use local files instead of http://
links? 

Please use cc to send your answers to me since I'm not yet subscribed to
the shale Mailing List.

?Thanks!
Cristi

Re: Broken URL's

[Cyril Bouteille]

Oops, sorry resending as plain text message:
 Cristi, I understand those taglib uris to be virtual only as unique 
keys for namespaces. They're not required to be a valid page for Shale 
or any other taglib.
You can use tagdir="/WEB-INF/tags" as an alternative to uris for your 
own tags, but I'm not sure it's going to help you here.

We'd need more details about the actual issue you're experiencing to help.

Cristi Magherusan wrote:

Hello,

I'm having a school project that must use shale, but it seems its
taglibs uri's are broken links, among others. Please someone fix them,
if possible. Also, is there a way to use local files instead of http://
links? 


Please use cc to send your answers to me since I'm not yet subscribed to
the shale Mailing List.

Thanks!
Cristi

  







smime.p7s
Description: S/MIME Cryptographic Signature

Re: Broken URL's

[Cyril Bouteille]

smime.p7s
Description: S/MIME Cryptographic Signature

RE: More dialogs in same time

[Gary VanMatre]

It seems like shale dialog generates an ID per view that is used to manage the 
dialog context and the id is attached to the view root.  It's been awhile since 
I've looked at this code but I want to say that you should be able to managed 
multiple dialogs per session as long as JSF client state saving is turned on.

Gary


 -- Original message --
From: <[EMAIL PROTECTED]>
> Rahul, thanks a lot!
> 
> By
> Mario 
> 
> -Original Message-
> From: Rahul Akolkar [mailto:[EMAIL PROTECTED] 
> Sent: 23 aprile 2008 23.21
> To: user@shale.apache.org
> Subject: Re: More dialogs in same time
> 
> On 4/23/08, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > Uhm, how can I start more DialogContext and use the correct one for
> each
> >  windows? So the problem is:
> >  I start dialog A from window 1 and window 2 of the same instance
> >  browser(sharing same httpsession). How can I use two different states
> >  from the two windows/dialogs?
> >
> 
> 
> OK, lets try to work on this together :-) but I'm heading out soon so
> I'll be slower to respond.
> 
> What have you tried? I had one potential suggestion for trying to move
> forward. Did you look at the programmatic approach? What didn't work?
> What are the dialogs doing i.e. are they talking to session scoped
> beans (ugh, in this case) or dialog scoped beans?
> 
> -Rahul
> 
> 
> >
> >  Mario
> >
> >  -Original Message-
> >  From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
> >
> > Sent: 23 aprile 2008 22.50
> >  To: user@shale.apache.org
> >  Subject: Re: More dialogs in same time
> >
> >  On 4/23/08, [EMAIL PROTECTED]
> >  <[EMAIL PROTECTED]> wrote:
> >  > I'm sorry Rahul for same post and also because I don't understand
> your
> >  >  response. How can I have two active dialogs at same times? I
> >  understood
> >  >  that shale store current state I HttpSession (or Managed beans
> with
> >  >  scope session).
> >  
> >
> >  There is one DialogContextManager per session. You can
> >  programmatically (or otherwise) start multiple dialogs (a.k.a.
> >  DialogContext instances). Starting the same dialog more than once
> (and
> >  at the same time) will have some additional caveats as I mentioned --
> >  I haven't tried it.
> >
> >
> >  >  Please send me some example
> >  >
> >  
> >
> >  I don't have any more examples that I can share. Please try to look
> at
> >  the example webapps (for dialogs)  -- say, from the v1.0.4 release --
> >  for working models of some of these concepts.
> >
> >  -Rahul
> >
> >
> >  >  Thanks
> >  >  Mario
> >  >
> >  >
> >  >  -Original Message-
> >  >  From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
> >  >  Sent: 23 aprile 2008 22.06
> >  >  To: user@shale.apache.org
> >  >  Subject: Re: More dialogs in same time
> >  >
> >  >  Please do not send the same post to both user and dev list
> >  separately.
> >  >  There is no benefit IMO to doing that.
> >  >
> >  >  On 4/23/08, [EMAIL PROTECTED]
> >  >  <[EMAIL PROTECTED]> wrote:
> >  >  > My customer want two or more instance of the same dialogs on
> >  different
> >  >  >  windows. The problem is that the windows are created by the
> same
> >  >  browser
> >  >  >  (window.open) and with IE (for example) this windows condivide
> the
> >  >  same
> >  >  >  HttpSession.
> >  >  >
> >  >  >  Is there a way to do it with Shale Dialog Manager?
> >  >  >
> >  >  
> >  >
> >  >  Probably more than one. For instance, one scenario could be
> setting
> >  up
> >  >  remoting [1] such that every time you hit a particular URL, a
> method
> >  >  binding processor starts an instance of a dialog programmatically
> >  [2],
> >  >  configured to taste etc. You could do window.open and friends.
> >  >
> >  >  The application-level question is how the managed beans that back
> the
> >  >  dialogs will react to multiple instances. Based on their design
> and
> >  >  scope, you could have dialog instances walking on each others
> toes.
> >  >
> >  >  -Rahul
> >  >
> >  >  [1] http://shale.apache.org/shale-remoting/
> >  >  [2] http://shale.apache.org/shale-dialog/
> >  >
> >  >
> >  >  >
> >  >  >
> >  >  >  Thank in advance
> >  >  >
> >  >  >  Mario
> >  >  >
> >  >  >
> 
> 
> 
> This message is for the designated recipient only and may contain privileged, 
> proprietary, or otherwise private information.  If you have received it in 
> error, please notify the sender immediately and delete the original.  Any 
> other 
> use of the email by you is prohibited.

RE: More dialogs in same time

[mario.buonopane]

Rahul, thanks a lot!

By
Mario 

-Original Message-
From: Rahul Akolkar [mailto:[EMAIL PROTECTED] 
Sent: 23 aprile 2008 23.21
To: user@shale.apache.org
Subject: Re: More dialogs in same time

On 4/23/08, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Uhm, how can I start more DialogContext and use the correct one for
each
>  windows? So the problem is:
>  I start dialog A from window 1 and window 2 of the same instance
>  browser(sharing same httpsession). How can I use two different states
>  from the two windows/dialogs?
>


OK, lets try to work on this together :-) but I'm heading out soon so
I'll be slower to respond.

What have you tried? I had one potential suggestion for trying to move
forward. Did you look at the programmatic approach? What didn't work?
What are the dialogs doing i.e. are they talking to session scoped
beans (ugh, in this case) or dialog scoped beans?

-Rahul


>
>  Mario
>
>  -Original Message-
>  From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
>
> Sent: 23 aprile 2008 22.50
>  To: user@shale.apache.org
>  Subject: Re: More dialogs in same time
>
>  On 4/23/08, [EMAIL PROTECTED]
>  <[EMAIL PROTECTED]> wrote:
>  > I'm sorry Rahul for same post and also because I don't understand
your
>  >  response. How can I have two active dialogs at same times? I
>  understood
>  >  that shale store current state I HttpSession (or Managed beans
with
>  >  scope session).
>  
>
>  There is one DialogContextManager per session. You can
>  programmatically (or otherwise) start multiple dialogs (a.k.a.
>  DialogContext instances). Starting the same dialog more than once
(and
>  at the same time) will have some additional caveats as I mentioned --
>  I haven't tried it.
>
>
>  >  Please send me some example
>  >
>  
>
>  I don't have any more examples that I can share. Please try to look
at
>  the example webapps (for dialogs)  -- say, from the v1.0.4 release --
>  for working models of some of these concepts.
>
>  -Rahul
>
>
>  >  Thanks
>  >  Mario
>  >
>  >
>  >  -Original Message-
>  >  From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
>  >  Sent: 23 aprile 2008 22.06
>  >  To: user@shale.apache.org
>  >  Subject: Re: More dialogs in same time
>  >
>  >  Please do not send the same post to both user and dev list
>  separately.
>  >  There is no benefit IMO to doing that.
>  >
>  >  On 4/23/08, [EMAIL PROTECTED]
>  >  <[EMAIL PROTECTED]> wrote:
>  >  > My customer want two or more instance of the same dialogs on
>  different
>  >  >  windows. The problem is that the windows are created by the
same
>  >  browser
>  >  >  (window.open) and with IE (for example) this windows condivide
the
>  >  same
>  >  >  HttpSession.
>  >  >
>  >  >  Is there a way to do it with Shale Dialog Manager?
>  >  >
>  >  
>  >
>  >  Probably more than one. For instance, one scenario could be
setting
>  up
>  >  remoting [1] such that every time you hit a particular URL, a
method
>  >  binding processor starts an instance of a dialog programmatically
>  [2],
>  >  configured to taste etc. You could do window.open and friends.
>  >
>  >  The application-level question is how the managed beans that back
the
>  >  dialogs will react to multiple instances. Based on their design
and
>  >  scope, you could have dialog instances walking on each others
toes.
>  >
>  >  -Rahul
>  >
>  >  [1] http://shale.apache.org/shale-remoting/
>  >  [2] http://shale.apache.org/shale-dialog/
>  >
>  >
>  >  >
>  >  >
>  >  >  Thank in advance
>  >  >
>  >  >  Mario
>  >  >
>  >  >



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

Re: More dialogs in same time

[Rahul Akolkar]

On 4/23/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Uhm, how can I start more DialogContext and use the correct one for each
>  windows? So the problem is:
>  I start dialog A from window 1 and window 2 of the same instance
>  browser(sharing same httpsession). How can I use two different states
>  from the two windows/dialogs?
>


OK, lets try to work on this together :-) but I'm heading out soon so
I'll be slower to respond.

What have you tried? I had one potential suggestion for trying to move
forward. Did you look at the programmatic approach? What didn't work?
What are the dialogs doing i.e. are they talking to session scoped
beans (ugh, in this case) or dialog scoped beans?

-Rahul


>
>  Mario
>
>  -Original Message-
>  From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
>
> Sent: 23 aprile 2008 22.50
>  To: user@shale.apache.org
>  Subject: Re: More dialogs in same time
>
>  On 4/23/08, [EMAIL PROTECTED]
>  <[EMAIL PROTECTED]> wrote:
>  > I'm sorry Rahul for same post and also because I don't understand your
>  >  response. How can I have two active dialogs at same times? I
>  understood
>  >  that shale store current state I HttpSession (or Managed beans with
>  >  scope session).
>  
>
>  There is one DialogContextManager per session. You can
>  programmatically (or otherwise) start multiple dialogs (a.k.a.
>  DialogContext instances). Starting the same dialog more than once (and
>  at the same time) will have some additional caveats as I mentioned --
>  I haven't tried it.
>
>
>  >  Please send me some example
>  >
>  
>
>  I don't have any more examples that I can share. Please try to look at
>  the example webapps (for dialogs)  -- say, from the v1.0.4 release --
>  for working models of some of these concepts.
>
>  -Rahul
>
>
>  >  Thanks
>  >  Mario
>  >
>  >
>  >  -Original Message-
>  >  From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
>  >  Sent: 23 aprile 2008 22.06
>  >  To: user@shale.apache.org
>  >  Subject: Re: More dialogs in same time
>  >
>  >  Please do not send the same post to both user and dev list
>  separately.
>  >  There is no benefit IMO to doing that.
>  >
>  >  On 4/23/08, [EMAIL PROTECTED]
>  >  <[EMAIL PROTECTED]> wrote:
>  >  > My customer want two or more instance of the same dialogs on
>  different
>  >  >  windows. The problem is that the windows are created by the same
>  >  browser
>  >  >  (window.open) and with IE (for example) this windows condivide the
>  >  same
>  >  >  HttpSession.
>  >  >
>  >  >  Is there a way to do it with Shale Dialog Manager?
>  >  >
>  >  
>  >
>  >  Probably more than one. For instance, one scenario could be setting
>  up
>  >  remoting [1] such that every time you hit a particular URL, a method
>  >  binding processor starts an instance of a dialog programmatically
>  [2],
>  >  configured to taste etc. You could do window.open and friends.
>  >
>  >  The application-level question is how the managed beans that back the
>  >  dialogs will react to multiple instances. Based on their design and
>  >  scope, you could have dialog instances walking on each others toes.
>  >
>  >  -Rahul
>  >
>  >  [1] http://shale.apache.org/shale-remoting/
>  >  [2] http://shale.apache.org/shale-dialog/
>  >
>  >
>  >  >
>  >  >
>  >  >  Thank in advance
>  >  >
>  >  >  Mario
>  >  >
>  >  >

RE: More dialogs in same time

[mario.buonopane]

Uhm, how can I start more DialogContext and use the correct one for each
windows? So the problem is:
I start dialog A from window 1 and window 2 of the same instance
browser(sharing same httpsession). How can I use two different states
from the two windows/dialogs?

Mario 

-Original Message-
From: Rahul Akolkar [mailto:[EMAIL PROTECTED] 
Sent: 23 aprile 2008 22.50
To: user@shale.apache.org
Subject: Re: More dialogs in same time

On 4/23/08, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> I'm sorry Rahul for same post and also because I don't understand your
>  response. How can I have two active dialogs at same times? I
understood
>  that shale store current state I HttpSession (or Managed beans with
>  scope session).


There is one DialogContextManager per session. You can
programmatically (or otherwise) start multiple dialogs (a.k.a.
DialogContext instances). Starting the same dialog more than once (and
at the same time) will have some additional caveats as I mentioned --
I haven't tried it.


>  Please send me some example
>


I don't have any more examples that I can share. Please try to look at
the example webapps (for dialogs)  -- say, from the v1.0.4 release --
for working models of some of these concepts.

-Rahul


>  Thanks
>  Mario
>
>
>  -Original Message-
>  From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
>  Sent: 23 aprile 2008 22.06
>  To: user@shale.apache.org
>  Subject: Re: More dialogs in same time
>
>  Please do not send the same post to both user and dev list
separately.
>  There is no benefit IMO to doing that.
>
>  On 4/23/08, [EMAIL PROTECTED]
>  <[EMAIL PROTECTED]> wrote:
>  > My customer want two or more instance of the same dialogs on
different
>  >  windows. The problem is that the windows are created by the same
>  browser
>  >  (window.open) and with IE (for example) this windows condivide the
>  same
>  >  HttpSession.
>  >
>  >  Is there a way to do it with Shale Dialog Manager?
>  >
>  
>
>  Probably more than one. For instance, one scenario could be setting
up
>  remoting [1] such that every time you hit a particular URL, a method
>  binding processor starts an instance of a dialog programmatically
[2],
>  configured to taste etc. You could do window.open and friends.
>
>  The application-level question is how the managed beans that back the
>  dialogs will react to multiple instances. Based on their design and
>  scope, you could have dialog instances walking on each others toes.
>
>  -Rahul
>
>  [1] http://shale.apache.org/shale-remoting/
>  [2] http://shale.apache.org/shale-dialog/
>
>
>  >
>  >
>  >  Thank in advance
>  >
>  >  Mario
>  >
>  >



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

Re: More dialogs in same time

[Rahul Akolkar]

On 4/23/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'm sorry Rahul for same post and also because I don't understand your
>  response. How can I have two active dialogs at same times? I understood
>  that shale store current state I HttpSession (or Managed beans with
>  scope session).


There is one DialogContextManager per session. You can
programmatically (or otherwise) start multiple dialogs (a.k.a.
DialogContext instances). Starting the same dialog more than once (and
at the same time) will have some additional caveats as I mentioned --
I haven't tried it.


>  Please send me some example
>


I don't have any more examples that I can share. Please try to look at
the example webapps (for dialogs)  -- say, from the v1.0.4 release --
for working models of some of these concepts.

-Rahul


>  Thanks
>  Mario
>
>
>  -Original Message-
>  From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
>  Sent: 23 aprile 2008 22.06
>  To: user@shale.apache.org
>  Subject: Re: More dialogs in same time
>
>  Please do not send the same post to both user and dev list separately.
>  There is no benefit IMO to doing that.
>
>  On 4/23/08, [EMAIL PROTECTED]
>  <[EMAIL PROTECTED]> wrote:
>  > My customer want two or more instance of the same dialogs on different
>  >  windows. The problem is that the windows are created by the same
>  browser
>  >  (window.open) and with IE (for example) this windows condivide the
>  same
>  >  HttpSession.
>  >
>  >  Is there a way to do it with Shale Dialog Manager?
>  >
>  
>
>  Probably more than one. For instance, one scenario could be setting up
>  remoting [1] such that every time you hit a particular URL, a method
>  binding processor starts an instance of a dialog programmatically [2],
>  configured to taste etc. You could do window.open and friends.
>
>  The application-level question is how the managed beans that back the
>  dialogs will react to multiple instances. Based on their design and
>  scope, you could have dialog instances walking on each others toes.
>
>  -Rahul
>
>  [1] http://shale.apache.org/shale-remoting/
>  [2] http://shale.apache.org/shale-dialog/
>
>
>  >
>  >
>  >  Thank in advance
>  >
>  >  Mario
>  >
>  >

RE: More dialogs in same time

[mario.buonopane]

I'm sorry Rahul for same post and also because I don't understand your
response. How can I have two active dialogs at same times? I understood
that shale store current state I HttpSession (or Managed beans with
scope session). 
Please send me some example

Thanks
Mario

-Original Message-
From: Rahul Akolkar [mailto:[EMAIL PROTECTED] 
Sent: 23 aprile 2008 22.06
To: user@shale.apache.org
Subject: Re: More dialogs in same time

Please do not send the same post to both user and dev list separately.
There is no benefit IMO to doing that.

On 4/23/08, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> My customer want two or more instance of the same dialogs on different
>  windows. The problem is that the windows are created by the same
browser
>  (window.open) and with IE (for example) this windows condivide the
same
>  HttpSession.
>
>  Is there a way to do it with Shale Dialog Manager?
>


Probably more than one. For instance, one scenario could be setting up
remoting [1] such that every time you hit a particular URL, a method
binding processor starts an instance of a dialog programmatically [2],
configured to taste etc. You could do window.open and friends.

The application-level question is how the managed beans that back the
dialogs will react to multiple instances. Based on their design and
scope, you could have dialog instances walking on each others toes.

-Rahul

[1] http://shale.apache.org/shale-remoting/
[2] http://shale.apache.org/shale-dialog/


>
>
>  Thank in advance
>
>  Mario
>
>



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

Re: More dialogs in same time

[Rahul Akolkar]

Please do not send the same post to both user and dev list separately.
There is no benefit IMO to doing that.

On 4/23/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> My customer want two or more instance of the same dialogs on different
>  windows. The problem is that the windows are created by the same browser
>  (window.open) and with IE (for example) this windows condivide the same
>  HttpSession.
>
>  Is there a way to do it with Shale Dialog Manager?
>


Probably more than one. For instance, one scenario could be setting up
remoting [1] such that every time you hit a particular URL, a method
binding processor starts an instance of a dialog programmatically [2],
configured to taste etc. You could do window.open and friends.

The application-level question is how the managed beans that back the
dialogs will react to multiple instances. Based on their design and
scope, you could have dialog instances walking on each others toes.

-Rahul

[1] http://shale.apache.org/shale-remoting/
[2] http://shale.apache.org/shale-dialog/


>
>
>  Thank in advance
>
>  Mario
>
>

Re: Shale web page

[Greg Reddin]

On Tue, Apr 15, 2008 at 5:19 PM, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
>  Since Greg mentioned he'd be away, I've tried to rectify it. Waiting
>  for the sync.

Thanks, sorry about that. I guess the mvn release:perform did that.

Greg

RE: NullPointerException in UIComponentBase decode using Shale test framework

[Zhen, Jane]

I figured that problem out, I needed to setRendererType, although just need to 
be null. Could anyone tell me why a component needs a null renderer?

I have a general question though. I am trying to create a view from a jsp page, 
normally you would do it in a backing bean in running environment where request 
and everything are set. All you need to do is to call ViewHandler.createView. 
But in shale framework, how would i set up everything in order to make it work? 
Is it even possible?
thanks
Jane

Re: Shale Homepage

[Rahul Akolkar]

On 4/15/08, Tyler Zale <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  It looks as if there is a small problem with some of the pages at
> http://shale.apache.org/
>
>  The index as well as a few others have goofed up navigation on the left
> side.
>


Thanks for the report, the site has been republished. It may take a
couple of hours to go live.

-Rahul


>  ...I don't think it is just my machine. ;-)
>
>
>  Regards,
>
>  TZ
>

Re: Shale web page

[Rahul Akolkar]

On 4/15/08, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 15, 2008 at 11:19 AM, linux.eavilesa
>  <[EMAIL PROTECTED]> wrote:
>
>  >  Where is shale web page?
>
>
> Oops.  Looks like someone deployed the site from the master POM.  Can
>  the guilty party please re-publish the website? :)
>


Since Greg mentioned he'd be away, I've tried to rectify it. Waiting
for the sync.

-Rahul

Re: Shale web page

[Wendy Smoak]

On Tue, Apr 15, 2008 at 11:19 AM, linux.eavilesa
<[EMAIL PROTECTED]> wrote:

>  Where is shale web page?

Oops.  Looks like someone deployed the site from the master POM.  Can
the guilty party please re-publish the website? :)

-- 
Wendy

RE: NullPointerException in UIComponentBase decode using Shale test framework

[Kito D. Mann]

Jane,

Can you give us a full stack trace (not sure which line threw the exception)
and the snippet of code where you initialize the components that you're
testing? I'm guessing that you just didn't initialize the components
properly -- Shale Test leaves that all up to the developer.

~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988


> -Original Message-
> From: Zhen, Jane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 15, 2008 9:22 AM
> To: user@shale.apache.org
> Subject: NullPointerException in UIComponentBase decode using Shale
> test framework
> 
> I simply created a Form and inside an inputTextField and tried to do
> decoding. But I got a java.lang.NullPointerException
> 
> at
> javax.faces.component.UIComponentBase.decode(UIComponentBase.java:685)
> 
> at javax.faces.component.UIInput.decode(UIInput.java:484)
> 
> at
> javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.ja
> va:905)
> 
> at javax.faces.component.UIInput.processDecodes(UIInput.java:400)
> 
> at
> com.hp.ed.configui.credential.CredentialBeanTest.testLabelUpdate(Creden
> tialBeanTest.java:70)
> 
> 
> 
> This has happened before, but I couldn't find an answer for that. I'm
> just giving it another try, as Shale test framework is really not well
> documented.
> 
> 
> 
> <>
> 
> UIViewRoot root=facesContext.getViewRoot();
> 
> List children = root.getChildren();
> 
> UIForm credForm = new HtmlForm();
> 
> credForm.setId("credForm");
> 
> credForm.setParent(root);
> 
> 
> 
> UIInput label = new HtmlInputText();
> 
> label.setId("label");
> 
> label.setParent(credForm);
> 
> ValueBinding vb =
> facesContext.getApplication().createValueBinding("#{credentialBean.pass
> wordAgain}");
> 
> label.setValueBinding("value", vb);
> 
> 
> 
> facesContext.getExternalContext().getRequestMap().put("credentialBean",
> vc);
> 
> facesContext.getExternalContext().getRequestParameterMap().put("credFor
> m.label","myLabel");
> 
> label.processDecodes(facesContext);  //if I don't call
> label.processDecodes, but root.processDecodes, then I don't get the
> exception, however, the submittedValue of inputText is null.
> 
> 
> 
> thanks for any help
> 
> 
> 
> Jane

RE: [Shale Clay]

[Gary VanMatre]

 -- Original message --
From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
> Yes, I am use JSF1.2 RI. It's been working for me (at least, the upload
> part of tomahawk). I am getting the current problem when I added shale
> in the mix.
>

I see.  It sounds like the clay view handler is having trouble replacing the 
state token then.  Something you might try is using the clay JSP tag.  That 
would help isolate the problem.

You could create a JSP page that has a f:view and shale:clay [1].  Then, for 
the jsfid, include the target template.  The token can be an HTML template or 
an entry in a clay config.

clay:clay id="address1" 
jsfid="classpath*:org/apache/shale/usecases/rolodex/address.html"
...
...

When the component is used with JSP, the default JSF runtime field marker 
replacement is used.

Please file a bug and a test case would be really nice :-)


[1] 
http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-clay-usecases/src/main/webapp/rolodex/jsprolodex.jsp?view=markup
Thanks,
Gary


 
> -Original Message-
> From: Gary VanMatre [mailto:[EMAIL PROTECTED] 
> Sent: Friday, April 11, 2008 4:15 PM
> To: user@shale.apache.org
> Subject: RE: [Shale Clay]
> 
> 
>  -- Original message --
> From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
> > I tried it and didn't seem to make a difference; it doesn't invoke the
> > action. It's really weird; without the "enctype" attribute, it at
> least
> > invokes the action; I suspect on postback, JSF doesn't restore the
> view
> > correctly because if I change my "javax.faces.STATE_SAVING_METHOD"
> from
> > client to "server", I see
> > 
> > ~com.sun.faces.saveStateFieldMarker~
> 
> Sounds like you are using JSF 1.2 with tomahawk?
> 
> 
> Gary
> 
> > 
> > at the bottom of the page.
> > 
> > -Original Message-
> > From: Ryan Wynn [mailto:[EMAIL PROTECTED] 
> > Sent: Friday, April 11, 2008 3:12 PM
> > To: user@shale.apache.org
> > Subject: Re: [Shale Clay]
> > 
> > On Fri, Apr 11, 2008 at 2:50 PM, Zheng, Xiahong
> <[EMAIL PROTECTED]>
> > wrote:
> > > I thought about this, but tomahawk doesn't seem to have a form
> > >  component.
> > >
> > >
> > >
> > >  -Original Message-
> > >  From: Gary VanMatre [mailto:[EMAIL PROTECTED]
> > >  Sent: Friday, April 11, 2008 1:35 PM
> > >  To: user@shale.apache.org
> > >  Subject: RE: [Shale Clay]
> > >
> > >  From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
> > >  > Thanks again. I have another question. How does shale work with
> > >  > fileload? I am trying to use t:fileUpload from tomahawk. I copied
> > the
> > >  > component definition into my clay-config.xml
> > >  >
> > >  >  > >  >   componentType="org.apache.myfaces.HtmlInputFileUpload"
> > >  >   extends="baseOutput>
> > >  >   
> > >  >   
> > >  >   .
> > >  >   
> > >  > 
> > >  >
> > >  > And I added the following in my html form
> > >  >
> > >  > 
> > >  >
> > >  >  > >  > storage="file" />
> > >  >
> > >  > 
> > >  >
> > >  > 
> > >  >
> > >  > When I hit the submit button, action method is never invoked.
> > >  > Interestingly, if I remove the "enctype" attribute, action method
> > is
> > >  > indeed invoked but the input is null which is expected. I have
> the
> > >  > extension filter configured.
> > >  >
> > >  > Any idea?
> > >  >
> > 
> > Can you try this?
> > 
> > 
> >
> >  
> >
> > 
> > 
> > +
> > 
> > 
> > 
> > That seems to be working ok for me.
> > 
> > Ryan
> > >
> > >  This is just a guess but you might try using the tomahawk form
> > component
> > >  too.  There might be some component coupling that is assumed in the
> > >  library.
> > >
> > >  Gary
> > >
> > >  >
> > >  >
> > >  > -Original Message-
> > >  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
> > >  > Sent: Friday, April 11, 2008 7:33 AM
> > >  > To: user@shale.ap

RE: [Shale Clay]

[Zheng, Xiahong]

Yes, I am use JSF1.2 RI. It's been working for me (at least, the upload
part of tomahawk). I am getting the current problem when I added shale
in the mix.

-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 11, 2008 4:15 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]


 -- Original message --
From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
> I tried it and didn't seem to make a difference; it doesn't invoke the
> action. It's really weird; without the "enctype" attribute, it at
least
> invokes the action; I suspect on postback, JSF doesn't restore the
view
> correctly because if I change my "javax.faces.STATE_SAVING_METHOD"
from
> client to "server", I see
> 
>   ~com.sun.faces.saveStateFieldMarker~

Sounds like you are using JSF 1.2 with tomahawk?


Gary

> 
> at the bottom of the page.
> 
> -Original Message-
> From: Ryan Wynn [mailto:[EMAIL PROTECTED] 
> Sent: Friday, April 11, 2008 3:12 PM
> To: user@shale.apache.org
> Subject: Re: [Shale Clay]
> 
> On Fri, Apr 11, 2008 at 2:50 PM, Zheng, Xiahong
<[EMAIL PROTECTED]>
> wrote:
> > I thought about this, but tomahawk doesn't seem to have a form
> >  component.
> >
> >
> >
> >  -Original Message-
> >  From: Gary VanMatre [mailto:[EMAIL PROTECTED]
> >  Sent: Friday, April 11, 2008 1:35 PM
> >  To: user@shale.apache.org
> >  Subject: RE: [Shale Clay]
> >
> >  From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
> >  > Thanks again. I have another question. How does shale work with
> >  > fileload? I am trying to use t:fileUpload from tomahawk. I copied
> the
> >  > component definition into my clay-config.xml
> >  >
> >  >  >  >   componentType="org.apache.myfaces.HtmlInputFileUpload"
> >  >   extends="baseOutput>
> >  >   
> >  >   
> >  >   .
> >  >   
> >  > 
> >  >
> >  > And I added the following in my html form
> >  >
> >  > 
> >  >
> >  >  >  > storage="file" />
> >  >
> >  > 
> >  >
> >  > 
> >  >
> >  > When I hit the submit button, action method is never invoked.
> >  > Interestingly, if I remove the "enctype" attribute, action method
> is
> >  > indeed invoked but the input is null which is expected. I have
the
> >  > extension filter configured.
> >  >
> >  > Any idea?
> >  >
> 
> Can you try this?
> 
> 
>
>  
>
> 
> 
> +
> 
> 
> 
> That seems to be working ok for me.
> 
> Ryan
> >
> >  This is just a guess but you might try using the tomahawk form
> component
> >  too.  There might be some component coupling that is assumed in the
> >  library.
> >
> >  Gary
> >
> >  >
> >  >
> >  > -Original Message-
> >  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
> >  > Sent: Friday, April 11, 2008 7:33 AM
> >  > To: user@shale.apache.org
> >  > Subject: RE: [Shale Clay]
> >  >
> >  > Yes.  Basically, you would have to define a component that
inherits
> >  from
> >  > h:dataTable, and give it child elements that inherit from
h:column.
> >  > Each of those child elements would then contain children that
make
> up
> >  > the content of your columns.
> >  >
> >  > Rich Eggert
> >  > Member of Technical Staff
> >  > Proteus Technologies, LLC
> >  > http://www.proteus-technologies.com
> >  >
> >  >
> >  >
> >  > -Original Message-
> >  > From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
> >  > Sent: Fri 4/11/2008 12:08 AM
> >  > To: user@shale.apache.org
> >  > Subject: RE: [Shale Clay]
> >  >
> >  > Thanks a lot Rich. I was able to use your first example without
> having
> >  > any white space issue even if I reformatted it a bit. If I want
to
> use
> >  > the second solution, how would I define the behavior of the
> dataTable?
> >  > Would it still need to inherit dataTable for the looping
capability
> >  > since the number of rows are dynamic?
> >  >
> >  > -Original Message-
> >  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
> >  > Sent: Thursday, April 10, 2008 5:12 PM
> >  > To: user@shale.apache.org
> >  &

RE: [Shale Clay]

[Gary VanMatre]

 -- Original message --
From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
> I tried it and didn't seem to make a difference; it doesn't invoke the
> action. It's really weird; without the "enctype" attribute, it at least
> invokes the action; I suspect on postback, JSF doesn't restore the view
> correctly because if I change my "javax.faces.STATE_SAVING_METHOD" from
> client to "server", I see
> 
>   ~com.sun.faces.saveStateFieldMarker~

Sounds like you are using JSF 1.2 with tomahawk?


Gary

> 
> at the bottom of the page.
> 
> -Original Message-
> From: Ryan Wynn [mailto:[EMAIL PROTECTED] 
> Sent: Friday, April 11, 2008 3:12 PM
> To: user@shale.apache.org
> Subject: Re: [Shale Clay]
> 
> On Fri, Apr 11, 2008 at 2:50 PM, Zheng, Xiahong <[EMAIL PROTECTED]>
> wrote:
> > I thought about this, but tomahawk doesn't seem to have a form
> >  component.
> >
> >
> >
> >  -Original Message-
> >  From: Gary VanMatre [mailto:[EMAIL PROTECTED]
> >  Sent: Friday, April 11, 2008 1:35 PM
> >  To: user@shale.apache.org
> >  Subject: RE: [Shale Clay]
> >
> >  From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
> >  > Thanks again. I have another question. How does shale work with
> >  > fileload? I am trying to use t:fileUpload from tomahawk. I copied
> the
> >  > component definition into my clay-config.xml
> >  >
> >  >  >  >   componentType="org.apache.myfaces.HtmlInputFileUpload"
> >  >   extends="baseOutput>
> >  >   
> >  >   
> >  >   .
> >  >   
> >  > 
> >  >
> >  > And I added the following in my html form
> >  >
> >  > 
> >  >
> >  >  >  > storage="file" />
> >  >
> >  > 
> >  >
> >  > 
> >  >
> >  > When I hit the submit button, action method is never invoked.
> >  > Interestingly, if I remove the "enctype" attribute, action method
> is
> >  > indeed invoked but the input is null which is expected. I have the
> >  > extension filter configured.
> >  >
> >  > Any idea?
> >  >
> 
> Can you try this?
> 
> 
>
>  
>
> 
> 
> +
> 
> 
> 
> That seems to be working ok for me.
> 
> Ryan
> >
> >  This is just a guess but you might try using the tomahawk form
> component
> >  too.  There might be some component coupling that is assumed in the
> >  library.
> >
> >  Gary
> >
> >  >
> >  >
> >  > -Original Message-
> >  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
> >  > Sent: Friday, April 11, 2008 7:33 AM
> >  > To: user@shale.apache.org
> >  > Subject: RE: [Shale Clay]
> >  >
> >  > Yes.  Basically, you would have to define a component that inherits
> >  from
> >  > h:dataTable, and give it child elements that inherit from h:column.
> >  > Each of those child elements would then contain children that make
> up
> >  > the content of your columns.
> >  >
> >  > Rich Eggert
> >  > Member of Technical Staff
> >  > Proteus Technologies, LLC
> >  > http://www.proteus-technologies.com
> >  >
> >  >
> >  >
> >  > -Original Message-
> >  > From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
> >  > Sent: Fri 4/11/2008 12:08 AM
> >  > To: user@shale.apache.org
> >  > Subject: RE: [Shale Clay]
> >  >
> >  > Thanks a lot Rich. I was able to use your first example without
> having
> >  > any white space issue even if I reformatted it a bit. If I want to
> use
> >  > the second solution, how would I define the behavior of the
> dataTable?
> >  > Would it still need to inherit dataTable for the looping capability
> >  > since the number of rows are dynamic?
> >  >
> >  > -Original Message-
> >  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
> >  > Sent: Thursday, April 10, 2008 5:12 PM
> >  > To: user@shale.apache.org
> >  > Subject: RE: [Shale Clay]
> >  >
> >  > My experience with dataTables and clay has been that they don't get
> >  > along very well, at least in the case of HTML templates (XML
> templates
> >  > are another story).  This is mainly because h:dataTable has a
> >  > dra

RE: [Shale Clay]

[Zheng, Xiahong]

Yes, I had  in my tempalte. 

-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 11, 2008 3:47 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]

This is just a shot in the dark, but have you tried wrapping the form
(or the whole page) in a tag that has jsfid="f:view"?

Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Fri 4/11/2008 3:34 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
 
I tried it and didn't seem to make a difference; it doesn't invoke the
action. It's really weird; without the "enctype" attribute, it at least
invokes the action; I suspect on postback, JSF doesn't restore the view
correctly because if I change my "javax.faces.STATE_SAVING_METHOD" from
client to "server", I see

~com.sun.faces.saveStateFieldMarker~

at the bottom of the page.

-Original Message-
From: Ryan Wynn [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 11, 2008 3:12 PM
To: user@shale.apache.org
Subject: Re: [Shale Clay]

On Fri, Apr 11, 2008 at 2:50 PM, Zheng, Xiahong <[EMAIL PROTECTED]>
wrote:
> I thought about this, but tomahawk doesn't seem to have a form
>  component.
>
>
>
>  -Original Message-
>  From: Gary VanMatre [mailto:[EMAIL PROTECTED]
>  Sent: Friday, April 11, 2008 1:35 PM
>  To: user@shale.apache.org
>  Subject: RE: [Shale Clay]
>
>  From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
>  > Thanks again. I have another question. How does shale work with
>  > fileload? I am trying to use t:fileUpload from tomahawk. I copied
the
>  > component definition into my clay-config.xml
>  >
>  >   >   componentType="org.apache.myfaces.HtmlInputFileUpload"
>  >   extends="baseOutput>
>  >   
>  >   
>  >   .
>  >   
>  > 
>  >
>  > And I added the following in my html form
>  >
>  > 
>  >
>  >   > storage="file" />
>  >
>  > 
>  >
>  > 
>  >
>  > When I hit the submit button, action method is never invoked.
>  > Interestingly, if I remove the "enctype" attribute, action method
is
>  > indeed invoked but the input is null which is expected. I have the
>  > extension filter configured.
>  >
>  > Any idea?
>  >

Can you try this?


   
 
   


+



That seems to be working ok for me.

Ryan
>
>  This is just a guess but you might try using the tomahawk form
component
>  too.  There might be some component coupling that is assumed in the
>  library.
>
>  Gary
>
>  >
>  >
>  > -Original Message-
>  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
>  > Sent: Friday, April 11, 2008 7:33 AM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > Yes.  Basically, you would have to define a component that inherits
>  from
>  > h:dataTable, and give it child elements that inherit from h:column.
>  > Each of those child elements would then contain children that make
up
>  > the content of your columns.
>  >
>  > Rich Eggert
>  > Member of Technical Staff
>  > Proteus Technologies, LLC
>  > http://www.proteus-technologies.com
>  >
>  >
>  >
>  > -Original Message-
>  > From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
>  > Sent: Fri 4/11/2008 12:08 AM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > Thanks a lot Rich. I was able to use your first example without
having
>  > any white space issue even if I reformatted it a bit. If I want to
use
>  > the second solution, how would I define the behavior of the
dataTable?
>  > Would it still need to inherit dataTable for the looping capability
>  > since the number of rows are dynamic?
>  >
>  > -Original Message-
>  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
>  > Sent: Thursday, April 10, 2008 5:12 PM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > My experience with dataTables and clay has been that they don't get
>  > along very well, at least in the case of HTML templates (XML
templates
>  > are another story).  This is mainly because h:dataTable has a
>  > drastically different structure from HTML tables.  h:dataTable
expects
>  > to have h:columns as its immediate child (with optional tags for
>  header
>  > and footer rows nested within each column), whereas HTML TABLE tags
>  > expect to h

RE: [Shale Clay]

[Richard Eggert]

This is just a shot in the dark, but have you tried wrapping the form (or the 
whole page) in a tag that has jsfid="f:view"?

Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Fri 4/11/2008 3:34 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
 
I tried it and didn't seem to make a difference; it doesn't invoke the
action. It's really weird; without the "enctype" attribute, it at least
invokes the action; I suspect on postback, JSF doesn't restore the view
correctly because if I change my "javax.faces.STATE_SAVING_METHOD" from
client to "server", I see

~com.sun.faces.saveStateFieldMarker~

at the bottom of the page.

-Original Message-
From: Ryan Wynn [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 11, 2008 3:12 PM
To: user@shale.apache.org
Subject: Re: [Shale Clay]

On Fri, Apr 11, 2008 at 2:50 PM, Zheng, Xiahong <[EMAIL PROTECTED]>
wrote:
> I thought about this, but tomahawk doesn't seem to have a form
>  component.
>
>
>
>  -Original Message-
>  From: Gary VanMatre [mailto:[EMAIL PROTECTED]
>  Sent: Friday, April 11, 2008 1:35 PM
>  To: user@shale.apache.org
>  Subject: RE: [Shale Clay]
>
>  From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
>  > Thanks again. I have another question. How does shale work with
>  > fileload? I am trying to use t:fileUpload from tomahawk. I copied
the
>  > component definition into my clay-config.xml
>  >
>  >   >   componentType="org.apache.myfaces.HtmlInputFileUpload"
>  >   extends="baseOutput>
>  >   
>  >   
>  >   .
>  >   
>  > 
>  >
>  > And I added the following in my html form
>  >
>  > 
>  >
>  >   > storage="file" />
>  >
>  > 
>  >
>  > 
>  >
>  > When I hit the submit button, action method is never invoked.
>  > Interestingly, if I remove the "enctype" attribute, action method
is
>  > indeed invoked but the input is null which is expected. I have the
>  > extension filter configured.
>  >
>  > Any idea?
>  >

Can you try this?


   
 
   


+



That seems to be working ok for me.

Ryan
>
>  This is just a guess but you might try using the tomahawk form
component
>  too.  There might be some component coupling that is assumed in the
>  library.
>
>  Gary
>
>  >
>  >
>  > -Original Message-
>  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
>  > Sent: Friday, April 11, 2008 7:33 AM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > Yes.  Basically, you would have to define a component that inherits
>  from
>  > h:dataTable, and give it child elements that inherit from h:column.
>  > Each of those child elements would then contain children that make
up
>  > the content of your columns.
>  >
>  > Rich Eggert
>  > Member of Technical Staff
>  > Proteus Technologies, LLC
>  > http://www.proteus-technologies.com
>  >
>  >
>  >
>  > -Original Message-
>  > From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
>  > Sent: Fri 4/11/2008 12:08 AM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > Thanks a lot Rich. I was able to use your first example without
having
>  > any white space issue even if I reformatted it a bit. If I want to
use
>  > the second solution, how would I define the behavior of the
dataTable?
>  > Would it still need to inherit dataTable for the looping capability
>  > since the number of rows are dynamic?
>  >
>  > -Original Message-
>  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
>  > Sent: Thursday, April 10, 2008 5:12 PM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > My experience with dataTables and clay has been that they don't get
>  > along very well, at least in the case of HTML templates (XML
templates
>  > are another story).  This is mainly because h:dataTable has a
>  > drastically different structure from HTML tables.  h:dataTable
expects
>  > to have h:columns as its immediate child (with optional tags for
>  header
>  > and footer rows nested within each column), whereas HTML TABLE tags
>  > expect to have TR (row) tags as its children (or TR tags nested
within
>  a
>  > TBODY), with the column (TD) tags nested within each row.
>  Essentially,
>  > from the point of view o

RE: [Shale Clay]

[Zheng, Xiahong]

I tried it and didn't seem to make a difference; it doesn't invoke the
action. It's really weird; without the "enctype" attribute, it at least
invokes the action; I suspect on postback, JSF doesn't restore the view
correctly because if I change my "javax.faces.STATE_SAVING_METHOD" from
client to "server", I see

~com.sun.faces.saveStateFieldMarker~

at the bottom of the page.

-Original Message-
From: Ryan Wynn [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 11, 2008 3:12 PM
To: user@shale.apache.org
Subject: Re: [Shale Clay]

On Fri, Apr 11, 2008 at 2:50 PM, Zheng, Xiahong <[EMAIL PROTECTED]>
wrote:
> I thought about this, but tomahawk doesn't seem to have a form
>  component.
>
>
>
>  -Original Message-
>  From: Gary VanMatre [mailto:[EMAIL PROTECTED]
>  Sent: Friday, April 11, 2008 1:35 PM
>  To: user@shale.apache.org
>  Subject: RE: [Shale Clay]
>
>  From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
>  > Thanks again. I have another question. How does shale work with
>  > fileload? I am trying to use t:fileUpload from tomahawk. I copied
the
>  > component definition into my clay-config.xml
>  >
>  >   >   componentType="org.apache.myfaces.HtmlInputFileUpload"
>  >   extends="baseOutput>
>  >   
>  >   
>  >   .
>  >   
>  > 
>  >
>  > And I added the following in my html form
>  >
>  > 
>  >
>  >   > storage="file" />
>  >
>  > 
>  >
>  > 
>  >
>  > When I hit the submit button, action method is never invoked.
>  > Interestingly, if I remove the "enctype" attribute, action method
is
>  > indeed invoked but the input is null which is expected. I have the
>  > extension filter configured.
>  >
>  > Any idea?
>  >

Can you try this?


   
 
   


+



That seems to be working ok for me.

Ryan
>
>  This is just a guess but you might try using the tomahawk form
component
>  too.  There might be some component coupling that is assumed in the
>  library.
>
>  Gary
>
>  >
>  >
>  > -Original Message-
>  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
>  > Sent: Friday, April 11, 2008 7:33 AM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > Yes.  Basically, you would have to define a component that inherits
>  from
>  > h:dataTable, and give it child elements that inherit from h:column.
>  > Each of those child elements would then contain children that make
up
>  > the content of your columns.
>  >
>  > Rich Eggert
>  > Member of Technical Staff
>  > Proteus Technologies, LLC
>  > http://www.proteus-technologies.com
>  >
>  >
>  >
>  > -Original Message-
>  > From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
>  > Sent: Fri 4/11/2008 12:08 AM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > Thanks a lot Rich. I was able to use your first example without
having
>  > any white space issue even if I reformatted it a bit. If I want to
use
>  > the second solution, how would I define the behavior of the
dataTable?
>  > Would it still need to inherit dataTable for the looping capability
>  > since the number of rows are dynamic?
>  >
>  > -Original Message-
>  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
>  > Sent: Thursday, April 10, 2008 5:12 PM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > My experience with dataTables and clay has been that they don't get
>  > along very well, at least in the case of HTML templates (XML
templates
>  > are another story).  This is mainly because h:dataTable has a
>  > drastically different structure from HTML tables.  h:dataTable
expects
>  > to have h:columns as its immediate child (with optional tags for
>  header
>  > and footer rows nested within each column), whereas HTML TABLE tags
>  > expect to have TR (row) tags as its children (or TR tags nested
within
>  a
>  > TBODY), with the column (TD) tags nested within each row.
>  Essentially,
>  > from the point of view of an h:dataTable, a column contains rows,
but
>  in
>  > an HTML TABLE, a row contains columns, which makes mapping between
the
>  > two extremely difficult.  It can be done, but it involves making a
lot
>  > of dummy jsfid="void" tags and using SPAN tags to cause elements
that
>  > wouldn't be visible in the mockup to be rendered at runtime.
>  >

Re: [Shale Clay]

[Ryan Wynn]

On Fri, Apr 11, 2008 at 2:50 PM, Zheng, Xiahong <[EMAIL PROTECTED]> wrote:
> I thought about this, but tomahawk doesn't seem to have a form
>  component.
>
>
>
>  -Original Message-
>  From: Gary VanMatre [mailto:[EMAIL PROTECTED]
>  Sent: Friday, April 11, 2008 1:35 PM
>  To: user@shale.apache.org
>  Subject: RE: [Shale Clay]
>
>  From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
>  > Thanks again. I have another question. How does shale work with
>  > fileload? I am trying to use t:fileUpload from tomahawk. I copied the
>  > component definition into my clay-config.xml
>  >
>  >   >   componentType="org.apache.myfaces.HtmlInputFileUpload"
>  >   extends="baseOutput>
>  >   
>  >   
>  >   .
>  >   
>  > 
>  >
>  > And I added the following in my html form
>  >
>  > 
>  >
>  >   > storage="file" />
>  >
>  > 
>  >
>  > 
>  >
>  > When I hit the submit button, action method is never invoked.
>  > Interestingly, if I remove the "enctype" attribute, action method is
>  > indeed invoked but the input is null which is expected. I have the
>  > extension filter configured.
>  >
>  > Any idea?
>  >

Can you try this?


   
 
   


+



That seems to be working ok for me.

Ryan
>
>  This is just a guess but you might try using the tomahawk form component
>  too.  There might be some component coupling that is assumed in the
>  library.
>
>  Gary
>
>  >
>  >
>  > -Original Message-
>  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
>  > Sent: Friday, April 11, 2008 7:33 AM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > Yes.  Basically, you would have to define a component that inherits
>  from
>  > h:dataTable, and give it child elements that inherit from h:column.
>  > Each of those child elements would then contain children that make up
>  > the content of your columns.
>  >
>  > Rich Eggert
>  > Member of Technical Staff
>  > Proteus Technologies, LLC
>  > http://www.proteus-technologies.com
>  >
>  >
>  >
>  > -Original Message-
>  > From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
>  > Sent: Fri 4/11/2008 12:08 AM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > Thanks a lot Rich. I was able to use your first example without having
>  > any white space issue even if I reformatted it a bit. If I want to use
>  > the second solution, how would I define the behavior of the dataTable?
>  > Would it still need to inherit dataTable for the looping capability
>  > since the number of rows are dynamic?
>  >
>  > -Original Message-
>  > From: Richard Eggert [mailto:[EMAIL PROTECTED]
>  > Sent: Thursday, April 10, 2008 5:12 PM
>  > To: user@shale.apache.org
>  > Subject: RE: [Shale Clay]
>  >
>  > My experience with dataTables and clay has been that they don't get
>  > along very well, at least in the case of HTML templates (XML templates
>  > are another story).  This is mainly because h:dataTable has a
>  > drastically different structure from HTML tables.  h:dataTable expects
>  > to have h:columns as its immediate child (with optional tags for
>  header
>  > and footer rows nested within each column), whereas HTML TABLE tags
>  > expect to have TR (row) tags as its children (or TR tags nested within
>  a
>  > TBODY), with the column (TD) tags nested within each row.
>  Essentially,
>  > from the point of view of an h:dataTable, a column contains rows, but
>  in
>  > an HTML TABLE, a row contains columns, which makes mapping between the
>  > two extremely difficult.  It can be done, but it involves making a lot
>  > of dummy jsfid="void" tags and using SPAN tags to cause elements that
>  > wouldn't be visible in the mockup to be rendered at runtime.
>  >
>  > e.g.,
>  >
>  >   > >
>  >Mock Heading
>  >   >>
>  >  #{foo.name}
>  >> facetName="header">
>  >   
>  >
>  > 
>  >
>  > Note that the lack of whitespace around the TR elements is intentional
>  > to avoid (blank) text elements winding up as children of the
>  h:dataTable
>  > component (which is very nasty and breaks everything!).
>  >
>  > As you can see, writing an HTML template for a dataTable gets
>  extremely
>  > ug

RE: [Shale Clay]

[Zheng, Xiahong]

I thought about this, but tomahawk doesn't seem to have a form
component. 

-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 11, 2008 1:35 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]

From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
> Thanks again. I have another question. How does shale work with
> fileload? I am trying to use t:fileUpload from tomahawk. I copied the
> component definition into my clay-config.xml
> 
>componentType="org.apache.myfaces.HtmlInputFileUpload"
>   extends="baseOutput>
>   
>   
>   .
>   
> 
> 
> And I added the following in my html form
> 
> 
> 
>  storage="file" />
> 
> 
> 
> 
> 
> When I hit the submit button, action method is never invoked.
> Interestingly, if I remove the "enctype" attribute, action method is
> indeed invoked but the input is null which is expected. I have the
> extension filter configured.
> 
> Any idea? 
>

This is just a guess but you might try using the tomahawk form component
too.  There might be some component coupling that is assumed in the
library.

Gary
 
>  
> 
> -Original Message-
> From: Richard Eggert [mailto:[EMAIL PROTECTED] 
> Sent: Friday, April 11, 2008 7:33 AM
> To: user@shale.apache.org
> Subject: RE: [Shale Clay]
> 
> Yes.  Basically, you would have to define a component that inherits
from
> h:dataTable, and give it child elements that inherit from h:column.
> Each of those child elements would then contain children that make up
> the content of your columns.
> 
> Rich Eggert
> Member of Technical Staff
> Proteus Technologies, LLC
> http://www.proteus-technologies.com
> 
> 
> 
> -Original Message-
> From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
> Sent: Fri 4/11/2008 12:08 AM
> To: user@shale.apache.org
> Subject: RE: [Shale Clay]
>  
> Thanks a lot Rich. I was able to use your first example without having
> any white space issue even if I reformatted it a bit. If I want to use
> the second solution, how would I define the behavior of the dataTable?
> Would it still need to inherit dataTable for the looping capability
> since the number of rows are dynamic?  
> 
> -Original Message-
> From: Richard Eggert [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 10, 2008 5:12 PM
> To: user@shale.apache.org
> Subject: RE: [Shale Clay]
> 
> My experience with dataTables and clay has been that they don't get
> along very well, at least in the case of HTML templates (XML templates
> are another story).  This is mainly because h:dataTable has a
> drastically different structure from HTML tables.  h:dataTable expects
> to have h:columns as its immediate child (with optional tags for
header
> and footer rows nested within each column), whereas HTML TABLE tags
> expect to have TR (row) tags as its children (or TR tags nested within
a
> TBODY), with the column (TD) tags nested within each row.
Essentially,
> from the point of view of an h:dataTable, a column contains rows, but
in
> an HTML TABLE, a row contains columns, which makes mapping between the
> two extremely difficult.  It can be done, but it involves making a lot
> of dummy jsfid="void" tags and using SPAN tags to cause elements that
> wouldn't be visible in the mockup to be rendered at runtime.
> 
> e.g.,
> 
>  >
>Mock Heading
> >
>  #{foo.name}
>   facetName="header">
>   
>
> 
> 
> Note that the lack of whitespace around the TR elements is intentional
> to avoid (blank) text elements winding up as children of the
h:dataTable
> component (which is very nasty and breaks everything!).
> 
> As you can see, writing an HTML template for a dataTable gets
extremely
> ugly very quickly.  For this reason, I don't recommend doing it unless
> you REALLY want to be able to view the mockup in a browser before
> deploying it.  You're better off defining the template in XML and just
> referring to it in the parent template, e.g.,
> 
> 
>Table goes here.
> 
> 
> 
> What we really need is a new JSF component that provides the same
> capabilities as dataTable but is structured more like HTML TABLE tags.
> 
> 
> 
> Rich Eggert
> Member of Technical Staff
> Proteus Technologies, LLC
> http://www.proteus-technologies.com
> 
> 
> 
> -Original Message-
> From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
> Sent: Thu 4/10/2008 2:22 PM
> To: user@shale.apache.org
> Subject: FW: [Shale Clay]
>  
> I couldn't seem to understand by looking at the clay usecase example.
> Can somebody post a simple example of using clay to generate a dynamic
> data table, the equivalent of the JSF h:dataTable tag? 
>  
> 
> 
> 
> 
> 

RE: [Shale Clay]

[Gary VanMatre]

From: "Zheng, Xiahong" <[EMAIL PROTECTED]>
> Thanks again. I have another question. How does shale work with
> fileload? I am trying to use t:fileUpload from tomahawk. I copied the
> component definition into my clay-config.xml
> 
>componentType="org.apache.myfaces.HtmlInputFileUpload"
>   extends="baseOutput>
>   
>   
>   .
>   
> 
> 
> And I added the following in my html form
> 
> 
> 
>  storage="file" />
> 
> 
> 
> 
> 
> When I hit the submit button, action method is never invoked.
> Interestingly, if I remove the "enctype" attribute, action method is
> indeed invoked but the input is null which is expected. I have the
> extension filter configured.
> 
> Any idea? 
>

This is just a guess but you might try using the tomahawk form component too.  
There might be some component coupling that is assumed in the library.

Gary
 
>  
> 
> -----Original Message-
> From: Richard Eggert [mailto:[EMAIL PROTECTED] 
> Sent: Friday, April 11, 2008 7:33 AM
> To: user@shale.apache.org
> Subject: RE: [Shale Clay]
> 
> Yes.  Basically, you would have to define a component that inherits from
> h:dataTable, and give it child elements that inherit from h:column.
> Each of those child elements would then contain children that make up
> the content of your columns.
> 
> Rich Eggert
> Member of Technical Staff
> Proteus Technologies, LLC
> http://www.proteus-technologies.com
> 
> 
> 
> -Original Message-
> From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
> Sent: Fri 4/11/2008 12:08 AM
> To: user@shale.apache.org
> Subject: RE: [Shale Clay]
>  
> Thanks a lot Rich. I was able to use your first example without having
> any white space issue even if I reformatted it a bit. If I want to use
> the second solution, how would I define the behavior of the dataTable?
> Would it still need to inherit dataTable for the looping capability
> since the number of rows are dynamic?  
> 
> -Original Message-
> From: Richard Eggert [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 10, 2008 5:12 PM
> To: user@shale.apache.org
> Subject: RE: [Shale Clay]
> 
> My experience with dataTables and clay has been that they don't get
> along very well, at least in the case of HTML templates (XML templates
> are another story).  This is mainly because h:dataTable has a
> drastically different structure from HTML tables.  h:dataTable expects
> to have h:columns as its immediate child (with optional tags for header
> and footer rows nested within each column), whereas HTML TABLE tags
> expect to have TR (row) tags as its children (or TR tags nested within a
> TBODY), with the column (TD) tags nested within each row.  Essentially,
> from the point of view of an h:dataTable, a column contains rows, but in
> an HTML TABLE, a row contains columns, which makes mapping between the
> two extremely difficult.  It can be done, but it involves making a lot
> of dummy jsfid="void" tags and using SPAN tags to cause elements that
> wouldn't be visible in the mockup to be rendered at runtime.
> 
> e.g.,
> 
>  >
>Mock Heading
> >
>  #{foo.name}
>   facetName="header">
>   
>
> 
> 
> Note that the lack of whitespace around the TR elements is intentional
> to avoid (blank) text elements winding up as children of the h:dataTable
> component (which is very nasty and breaks everything!).
> 
> As you can see, writing an HTML template for a dataTable gets extremely
> ugly very quickly.  For this reason, I don't recommend doing it unless
> you REALLY want to be able to view the mockup in a browser before
> deploying it.  You're better off defining the template in XML and just
> referring to it in the parent template, e.g.,
> 
> 
>Table goes here.
> 
> 
> 
> What we really need is a new JSF component that provides the same
> capabilities as dataTable but is structured more like HTML TABLE tags.
> 
> 
> 
> Rich Eggert
> Member of Technical Staff
> Proteus Technologies, LLC
> http://www.proteus-technologies.com
> 
> 
> 
> -Original Message-
> From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
> Sent: Thu 4/10/2008 2:22 PM
> To: user@shale.apache.org
> Subject: FW: [Shale Clay]
>  
> I couldn't seem to understand by looking at the clay usecase example.
> Can somebody post a simple example of using clay to generate a dynamic
> data table, the equivalent of the JSF h:dataTable tag? 
>  
> 
> 
> 
> 
> 

RE: [Shale Clay]

[Richard Eggert]

I don't see anything wrong with what you've written there (I would add 
type="file" to your  tag so that it looks right if you view it offline 
in a browser, but that shouldn't affect how Clay treats it).  Does it let you 
select a file before submitting?  

Double-check to make sure that you don't have any mistakes in your 
configuration (especially in web.xml).  Check the log for errors as well (you 
may need to tweak the log settings to get useful information).  I've used 
t:inputFileUpload with Clay many times, so I'm sure it works.

By the way, it generally isn't necessary to copy the component definitions into 
your clay-config.xml file.  Just add 
classpath*:META-INF/tomahawk-1_1_3-config.xml to the 
org.apache.shale.clay.COMMON_CONFIG_FILES context parameter in your web.xml 
file, and you'll get the definitions of all the Tomahawk components.



Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Fri 4/11/2008 12:19 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
 
Thanks again. I have another question. How does shale work with
fileload? I am trying to use t:fileUpload from tomahawk. I copied the
component definition into my clay-config.xml


.
  


And I added the following in my html form









When I hit the submit button, action method is never invoked.
Interestingly, if I remove the "enctype" attribute, action method is
indeed invoked but the input is null which is expected. I have the
extension filter configured.

Any idea? 

 

-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 11, 2008 7:33 AM
To: user@shale.apache.org
Subject: RE: [Shale Clay]

Yes.  Basically, you would have to define a component that inherits from
h:dataTable, and give it child elements that inherit from h:column.
Each of those child elements would then contain children that make up
the content of your columns.

Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Fri 4/11/2008 12:08 AM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
 
Thanks a lot Rich. I was able to use your first example without having
any white space issue even if I reformatted it a bit. If I want to use
the second solution, how would I define the behavior of the dataTable?
Would it still need to inherit dataTable for the looping capability
since the number of rows are dynamic?  

-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 10, 2008 5:12 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]

My experience with dataTables and clay has been that they don't get
along very well, at least in the case of HTML templates (XML templates
are another story).  This is mainly because h:dataTable has a
drastically different structure from HTML tables.  h:dataTable expects
to have h:columns as its immediate child (with optional tags for header
and footer rows nested within each column), whereas HTML TABLE tags
expect to have TR (row) tags as its children (or TR tags nested within a
TBODY), with the column (TD) tags nested within each row.  Essentially,
from the point of view of an h:dataTable, a column contains rows, but in
an HTML TABLE, a row contains columns, which makes mapping between the
two extremely difficult.  It can be done, but it involves making a lot
of dummy jsfid="void" tags and using SPAN tags to cause elements that
wouldn't be visible in the mockup to be rendered at runtime.

e.g.,


   Mock Heading

 #{foo.name}
 
  
   


Note that the lack of whitespace around the TR elements is intentional
to avoid (blank) text elements winding up as children of the h:dataTable
component (which is very nasty and breaks everything!).

As you can see, writing an HTML template for a dataTable gets extremely
ugly very quickly.  For this reason, I don't recommend doing it unless
you REALLY want to be able to view the mockup in a browser before
deploying it.  You're better off defining the template in XML and just
referring to it in the parent template, e.g.,


   Table goes here.



What we really need is a new JSF component that provides the same
capabilities as dataTable but is structured more like HTML TABLE tags.



Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Thu 4/10/2008 2:22 PM
To: user@shale.apache.org
Subject: FW: [Shale Clay]
 
I couldn't seem to understand by looking at the clay usecase example.
Can somebody post a simple example of using clay to generate a dynamic
data table, the equivalent of the JSF h:dataTable tag? 
 

RE: [Shale Clay]

[Zheng, Xiahong]

Thanks again. I have another question. How does shale work with
fileload? I am trying to use t:fileUpload from tomahawk. I copied the
component definition into my clay-config.xml


.
  


And I added the following in my html form









When I hit the submit button, action method is never invoked.
Interestingly, if I remove the "enctype" attribute, action method is
indeed invoked but the input is null which is expected. I have the
extension filter configured.

Any idea? 

 

-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 11, 2008 7:33 AM
To: user@shale.apache.org
Subject: RE: [Shale Clay]

Yes.  Basically, you would have to define a component that inherits from
h:dataTable, and give it child elements that inherit from h:column.
Each of those child elements would then contain children that make up
the content of your columns.

Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Fri 4/11/2008 12:08 AM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
 
Thanks a lot Rich. I was able to use your first example without having
any white space issue even if I reformatted it a bit. If I want to use
the second solution, how would I define the behavior of the dataTable?
Would it still need to inherit dataTable for the looping capability
since the number of rows are dynamic?  

-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 10, 2008 5:12 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]

My experience with dataTables and clay has been that they don't get
along very well, at least in the case of HTML templates (XML templates
are another story).  This is mainly because h:dataTable has a
drastically different structure from HTML tables.  h:dataTable expects
to have h:columns as its immediate child (with optional tags for header
and footer rows nested within each column), whereas HTML TABLE tags
expect to have TR (row) tags as its children (or TR tags nested within a
TBODY), with the column (TD) tags nested within each row.  Essentially,
from the point of view of an h:dataTable, a column contains rows, but in
an HTML TABLE, a row contains columns, which makes mapping between the
two extremely difficult.  It can be done, but it involves making a lot
of dummy jsfid="void" tags and using SPAN tags to cause elements that
wouldn't be visible in the mockup to be rendered at runtime.

e.g.,


   Mock Heading

 #{foo.name}
 
  
   


Note that the lack of whitespace around the TR elements is intentional
to avoid (blank) text elements winding up as children of the h:dataTable
component (which is very nasty and breaks everything!).

As you can see, writing an HTML template for a dataTable gets extremely
ugly very quickly.  For this reason, I don't recommend doing it unless
you REALLY want to be able to view the mockup in a browser before
deploying it.  You're better off defining the template in XML and just
referring to it in the parent template, e.g.,


   Table goes here.



What we really need is a new JSF component that provides the same
capabilities as dataTable but is structured more like HTML TABLE tags.



Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Thu 4/10/2008 2:22 PM
To: user@shale.apache.org
Subject: FW: [Shale Clay]
 
I couldn't seem to understand by looking at the clay usecase example.
Can somebody post a simple example of using clay to generate a dynamic
data table, the equivalent of the JSF h:dataTable tag? 
 

Re: Need to escape special characters in Shale validator script

[Gary VanMatre]

You might try wrapping the script in a CDATA before trying to escape the JS.







 -- Original message --
From: Jeff Tsay <[EMAIL PROTECTED]>
> Hi,
> 
> I'm trying to use Shale validator with xulfaces. (XUL is a user 
> interface language that is a type of XML) The first problem I'm having 
> is that
> 
> 
> is encoded as follows:
> 
> 

RE: [Shale Clay]

[Richard Eggert]

Yes.  Basically, you would have to define a component that inherits from 
h:dataTable, and give it child elements that inherit from h:column.  Each of 
those child elements would then contain children that make up the content of 
your columns.

Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Fri 4/11/2008 12:08 AM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
 
Thanks a lot Rich. I was able to use your first example without having
any white space issue even if I reformatted it a bit. If I want to use
the second solution, how would I define the behavior of the dataTable?
Would it still need to inherit dataTable for the looping capability
since the number of rows are dynamic?  

-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 10, 2008 5:12 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]

My experience with dataTables and clay has been that they don't get
along very well, at least in the case of HTML templates (XML templates
are another story).  This is mainly because h:dataTable has a
drastically different structure from HTML tables.  h:dataTable expects
to have h:columns as its immediate child (with optional tags for header
and footer rows nested within each column), whereas HTML TABLE tags
expect to have TR (row) tags as its children (or TR tags nested within a
TBODY), with the column (TD) tags nested within each row.  Essentially,
from the point of view of an h:dataTable, a column contains rows, but in
an HTML TABLE, a row contains columns, which makes mapping between the
two extremely difficult.  It can be done, but it involves making a lot
of dummy jsfid="void" tags and using SPAN tags to cause elements that
wouldn't be visible in the mockup to be rendered at runtime.

e.g.,


   Mock Heading

 #{foo.name}
 
  
   


Note that the lack of whitespace around the TR elements is intentional
to avoid (blank) text elements winding up as children of the h:dataTable
component (which is very nasty and breaks everything!).

As you can see, writing an HTML template for a dataTable gets extremely
ugly very quickly.  For this reason, I don't recommend doing it unless
you REALLY want to be able to view the mockup in a browser before
deploying it.  You're better off defining the template in XML and just
referring to it in the parent template, e.g.,


   Table goes here.



What we really need is a new JSF component that provides the same
capabilities as dataTable but is structured more like HTML TABLE tags.



Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Thu 4/10/2008 2:22 PM
To: user@shale.apache.org
Subject: FW: [Shale Clay]
 
I couldn't seem to understand by looking at the clay usecase example.
Can somebody post a simple example of using clay to generate a dynamic
data table, the equivalent of the JSF h:dataTable tag? 
 

RE: [Shale Clay]

[Zheng, Xiahong]

Thanks a lot Rich. I was able to use your first example without having
any white space issue even if I reformatted it a bit. If I want to use
the second solution, how would I define the behavior of the dataTable?
Would it still need to inherit dataTable for the looping capability
since the number of rows are dynamic?  

-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 10, 2008 5:12 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]

My experience with dataTables and clay has been that they don't get
along very well, at least in the case of HTML templates (XML templates
are another story).  This is mainly because h:dataTable has a
drastically different structure from HTML tables.  h:dataTable expects
to have h:columns as its immediate child (with optional tags for header
and footer rows nested within each column), whereas HTML TABLE tags
expect to have TR (row) tags as its children (or TR tags nested within a
TBODY), with the column (TD) tags nested within each row.  Essentially,
from the point of view of an h:dataTable, a column contains rows, but in
an HTML TABLE, a row contains columns, which makes mapping between the
two extremely difficult.  It can be done, but it involves making a lot
of dummy jsfid="void" tags and using SPAN tags to cause elements that
wouldn't be visible in the mockup to be rendered at runtime.

e.g.,


   Mock Heading

 #{foo.name}
 
  
   


Note that the lack of whitespace around the TR elements is intentional
to avoid (blank) text elements winding up as children of the h:dataTable
component (which is very nasty and breaks everything!).

As you can see, writing an HTML template for a dataTable gets extremely
ugly very quickly.  For this reason, I don't recommend doing it unless
you REALLY want to be able to view the mockup in a browser before
deploying it.  You're better off defining the template in XML and just
referring to it in the parent template, e.g.,


   Table goes here.



What we really need is a new JSF component that provides the same
capabilities as dataTable but is structured more like HTML TABLE tags.



Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Thu 4/10/2008 2:22 PM
To: user@shale.apache.org
Subject: FW: [Shale Clay]
 
I couldn't seem to understand by looking at the clay usecase example.
Can somebody post a simple example of using clay to generate a dynamic
data table, the equivalent of the JSF h:dataTable tag? 
 

Re: Nightly Builds

[Greg Reddin]

Try this for the 1.0.X branch:

svn co 
https://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/

and this for the trunk:

svn co https://svn.apache.org/repos/asf/shale/framework/trunk

Greg



On Thu, Apr 10, 2008 at 3:34 PM, Tyler Zale <[EMAIL PROTECTED]> wrote:
> Greg Reddin wrote:
>
> > Probably your only option at the current time is to check out the
> > 1.0.X branch from svn and build locally. If you can figure out what's
> > wrong with the trunk and submit a patch I will owe you greatly :-)
> >
> > Thanks,
> > Greg
> >
>
>  Thanks for the update.
>
>  I would love to get involved and help out (cause I think shale is flipping
> amazing), but I have to figure out how Maven works first...
>
>  Unless there is a good old fashion svn somewhere (All I see hosted on the
> svn is a maven .pom, so I'll take that as a hint.).
>
>
>  Regards,
>  TZ
>

RE: [Shale Clay]

[Richard Eggert]

My experience with dataTables and clay has been that they don't get along very 
well, at least in the case of HTML templates (XML templates are another story). 
 This is mainly because h:dataTable has a drastically different structure from 
HTML tables.  h:dataTable expects to have h:columns as its immediate child 
(with optional tags for header and footer rows nested within each column), 
whereas HTML TABLE tags expect to have TR (row) tags as its children (or TR 
tags nested within a TBODY), with the column (TD) tags nested within each row.  
Essentially, from the point of view of an h:dataTable, a column contains rows, 
but in an HTML TABLE, a row contains columns, which makes mapping between the 
two extremely difficult.  It can be done, but it involves making a lot of dummy 
jsfid="void" tags and using SPAN tags to cause elements that wouldn't be 
visible in the mockup to be rendered at runtime.

e.g.,


   Mock Heading

 #{foo.name}
 
  
   


Note that the lack of whitespace around the TR elements is intentional to avoid 
(blank) text elements winding up as children of the h:dataTable component 
(which is very nasty and breaks everything!).

As you can see, writing an HTML template for a dataTable gets extremely ugly 
very quickly.  For this reason, I don't recommend doing it unless you REALLY 
want to be able to view the mockup in a browser before deploying it.  You're 
better off defining the template in XML and just referring to it in the parent 
template, e.g.,


   Table goes here.



What we really need is a new JSF component that provides the same capabilities 
as dataTable but is structured more like HTML TABLE tags.



Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Thu 4/10/2008 2:22 PM
To: user@shale.apache.org
Subject: FW: [Shale Clay]
 
I couldn't seem to understand by looking at the clay usecase example.
Can somebody post a simple example of using clay to generate a dynamic
data table, the equivalent of the JSF h:dataTable tag? 
 

Re: Nightly Builds

[Tyler Zale]

Greg Reddin wrote:

Probably your only option at the current time is to check out the
1.0.X branch from svn and build locally. If you can figure out what's
wrong with the trunk and submit a patch I will owe you greatly :-)

Thanks,
Greg


Thanks for the update.

I would love to get involved and help out (cause I think shale is 
flipping amazing), but I have to figure out how Maven works first...


Unless there is a good old fashion svn somewhere (All I see hosted on 
the svn is a maven .pom, so I'll take that as a hint.).



Regards,
TZ

Re: Nightly Builds

[Greg Reddin]

On Tue, Apr 8, 2008 at 12:34 PM, Tyler Zale <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Where do I have to go to get the nightly builds / snapshots?

Sorry we haven't gotten back to you until now, and doubly sorry I
don't have better news.

If we ever hosted downloadable assemblies of the nightly builds I'm
betting they are badly out of date and I don't know where to find
them.

Until just a few weeks ago the 1.0.X branch wouldn't even build so I'm
pretty sure nightlies have not been produced in quite a while. The
trunk currently has the same problem and it's on my todo list to try
and fix it, but it will take me a while to get to it. Perhaps we
should set up a Continuum build at least for the 1.0.X branch now that
it builds.

Probably your only option at the current time is to check out the
1.0.X branch from svn and build locally. If you can figure out what's
wrong with the trunk and submit a patch I will owe you greatly :-)

Thanks,
Greg

Re: AW: [ANNOUNCE] New Shale PMC Chair

[Gary VanMatre]

>From: Tomasz Pasierb <[EMAIL PROTECTED]> 
> 
> Gary VanMatre wrote: 
> > Many have told me that Facelets has clearly won and we should just try 
> > to help them out JSF 2 will be featured from facelets. 
> 
> Gary, are you saying that you're thinking about stopping the development 
> of clay? Should we switch to facelets? 
>

When JSF 2 is released, it might be worth looking into the new page definition 
languange (PDL).  In terms of new clay developement, that will depend on the 
community.  I've not had a chance to use Clay outside of just building it.  
Ryan and others pushed for many of the features.

 
> Regadrds, 
> Tom 

Gary

Re: AW: [ANNOUNCE] New Shale PMC Chair

[Tomasz Pasierb]

Gary VanMatre wrote:
Many have told me that Facelets has clearly won and we should just try 
to help them out JSF 2 will be featured from facelets.


Gary, are you saying that you're thinking about stopping the development 
of clay? Should we switch to facelets?


Regadrds,
Tom

Re: AW: [ANNOUNCE] New Shale PMC Chair

[Greg Reddin]

On Thu, Mar 27, 2008 at 12:20 PM, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
>  Many have told me that Facelets has clearly won and we should just try to 
> help them out JSF 2 will be featured from facelets.

Yeah, but... Many have also complained that there hasn't been much
movement in Facelets of late and the project has been hard to get
into, so maybe... :-)

Greg

Re: AW: [ANNOUNCE] New Shale PMC Chair

[Gary VanMatre]

>From: "Bernhard Slominski" <[EMAIL PROTECTED]> 
>
> > -Ursprüngliche Nachricht- 
> > Von: Gary VanMatre [mailto:[EMAIL PROTECTED] 
> > Gesendet: Montag, 24. März 2008 19:31 
> > An: user@shale.apache.org 
> > Betreff: RE: [ANNOUNCE] New Shale PMC Chair 
> > 
> > 
> > >From: 
> > > 
> > > Congrats Gary! I hope Shale restart the development. 
> > > 
> > 
> > Yeah, I have a few new Clay ideas but all are JSF 1.2ish. 
> 
> I also hope that Shale has some future (that were my last words at the JSF 
> days 
> presentation about Shale: It's not yet dead !). 
> For the Clay vs. Facelets: I think one major problem is really the confusing 
> naming (HTML, full HTML, full XML ...) and documentation of Clay, there 
> should 
> be put some effort in there. 
>

Good point.  Bad terms with probably too many options.  Clay can be used with 
JSP or as a page entry point like facelets.  The template can be non-xhtml, 
xhtml or an abstract reference defined in XML that doesn't correspond to a 
physical resource similar to tiles.  The templates can be loaded from the 
context root or from the classpath.  Clay templates allow inheritance in 
addition to composition.

Many have told me that Facelets has clearly won and we should just try to help 
them out JSF 2 will be featured from facelets.




> Bernhard 


Gary

RE: [ANNOUNCE] New Shale PMC Chair

[Gary VanMatre]

>From: <[EMAIL PROTECTED]> 
>
> Congrats Gary! I hope Shale restart the development. 
> 

Yeah, I have a few new Clay ideas but all are JSF 1.2ish.
   * Refactor clay config beans with interfaces and impl.  Way back I started 
looking at using JPA entity beans to define clay configs.  My hope was to make 
the entity beans implement common interfaces making them config beans.
   * Custom EL function support.
   * Defining template config using annotations.

I sorta lost momentum with the popularity of facelets and JSF 2.0 planning.  I 
think the last Clay feature that I added was metadata to represent the java 
final modifier [1].

The template "inheritance", symbols and pre-htmlx support are really the only 
unique features over the others (facelets & JSF templating) and they are now 
the de facto standard.  

[1] https://issues.apache.org/struts/browse/SHALE-353


Gary

> Mario 
> 
> -Original Message- 
> From: Greg Reddin [mailto:[EMAIL PROTECTED] 
> Sent: 20 marzo 2008 15.41 
> To: user@shale.apache.org; [EMAIL PROTECTED] 
> Subject: [ANNOUNCE] New Shale PMC Chair 
> 
> In its meeting yesterday the Apache Board of Directors unanimously 
> approved a resolution naming Gary VanMatre the new chair of the Apache 
> Shale Project Management Committee. Please join us in congratulating 
> Gary for this new role. 
> 
> In addition we would like to publicly thank Craig McClanahan for his 
> service to this project and his invaluable contribution to the Java 
> web application development community. We are endlessly grateful to 
> him for his role in defining the JavaServer Faces framework and, more 
> specifically, in birthing the Shale project. It is no small loss to 
> this community that his work has made it difficult for him to be as 
> involved as he once was. At his own request, Craig is now an emeritus 
> member of the Shale PMC. 
> 
> Thank you, 
> Greg Reddin 
> Apache Shale PMC Member 
> 
> 
> 
> This message is for the designated recipient only and may contain privileged, 
> proprietary, or otherwise private information. If you have received it in 
> error, please notify the sender immediately and delete the original. Any 
> other 
> use of the email by you is prohibited.