You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "David G. Friedman" <hu...@ix.netcom.com> on 2005/08/20 09:09:00 UTC

[Shale] What's the deal with the dollar signs?

I thought I'd read some Shale documents a while ago mentioning the purpose
for the dollar signs in the example use cases but while speed-reading though
various Shale documents, I'm totally missing that.  Can someone point that
out to me?

Thanks,
David


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: [Shale] What's the deal with the dollar signs?

Posted by Craig McClanahan <cr...@gmail.com>.
On 8/20/05, David G. Friedman <hu...@ix.netcom.com> wrote:
> Craig,
> 
> I was actually referring to the class names. I was
> confused by the use cases app which didn't list
> the faces ViewHandler, NavigationHandler, etc.
> Is there another working example which could show
> me how those work?  I only saw the use case using
> the ShaleFilter, not the Shale JSF parts.

OK, I am sure I am too close to the forest to see the trees that you
think are standing in your way :-), but there is likely to be a key
feature of JSF that is leading to this question.  A JSF implementation
is *required* (by the spec) to recognize any
"META-INF/faces-config.xml" resource in any JAR file under
"/WEB-INF/lib" at app startup time.  Among other things, this means
that you can *transparently* register a custom ViewHandler (or
whatever) without requiring any changes to the app's web.xml
descriptor.  Just inclue the appropriate JAR, and all the relevant
registration occurs auto-magically.

In relationship to Shale, then, you need to understand which of the
JAR files include a "META-INF/faces-config.xml" resource, and what
things those resources cause to be registered.  Just as one example,
the fact that "shale-core.jar" includes a "META-INF/faces-config.xml"
resource explains how the event notifications for a ViewHandler are
actually implemented.

The beauty of the mechanism, of course, is that it works equally well
for JSF component libraries that you might choose to include in your
application -- the existence of an appropriate resource file inside
the JAR triggers *automatic* registration of those components with the
JSF runtime -- no custom web.xml settings are required.

This kind of auto-registration of config files is available in a
Servlet 2.3 (or later) environment, because that's where the
ServletContext.getResourcePaths() method first became available.  For
JSF, that's not an issue since Servlet 2.3 is the minimum base
platform.  But it's definitely an issue for Struts 1.x, which has (at
least through 1.2.x) depended solely on Servlet 2.2 facilities.

>  As for
> why, I was wondering if Shale could work with FaceLets
> but after reading the API which suggests using the
> ShaleViewHandler, I'm doubting it since I don't
> think JSF can use multiple ViewHandlers in one
> webapp/JSF-config.
> 

ViewHandler implementations, if they are properly designed, can be
cascaded.  Indeed, Shale already includes two such implementations
(one for Tiles Standalone, and one for the ViewController event firing
behavior).

On the particular issue of Shale+Facelets, there is absolutely no
reason they should *not* work together transparently -- that's the
benefit of starting from a common base API.  I can't endorse it as
actually working, though, until I have had enough time to verify that
for myself -- and gaps between international travel issues mean I
might actually be able to play with this combination over the next
couple of weeks.


> Regards,
> David
> 

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


RE: [Shale] What's the deal with the dollar signs?

Posted by "David G. Friedman" <hu...@ix.netcom.com>.
Craig,

I was actually referring to the class names. I was
confused by the use cases app which didn't list
the faces ViewHandler, NavigationHandler, etc.
Is there another working example which could show
me how those work?  I only saw the use case using
the ShaleFilter, not the Shale JSF parts.  As for
why, I was wondering if Shale could work with FaceLets
but after reading the API which suggests using the
ShaleViewHandler, I'm doubting it since I don't
think JSF can use multiple ViewHandlers in one
webapp/JSF-config.

Regards,
David

-----Original Message-----
From: Craig McClanahan [mailto:craigmcc@gmail.com]
Sent: Saturday, August 20, 2005 4:08 AM
To: Struts Users Mailing List
Subject: Re: [Shale] What's the deal with the dollar signs?


On 8/20/05, David G. Friedman <hu...@ix.netcom.com> wrote:
> I thought I'd read some Shale documents a while ago mentioning the purpose
> for the dollar signs in the example use cases but while speed-reading
though
> various Shale documents, I'm totally missing that.  Can someone point that
> out to me?
>

I'm not positive what "dollar signs" you are referring to ... but
there are two delimiters for dynamic expressions that might be of
interest:

* "${xxx}" is typically an expression in the syntax/semantics supported
  by the JSP Standard Tag Library (JSTL), as well as that supported by
  JSP 2.0.  These expressions are evaluated as the page is rendered,
  and are dynamically replaced by the result of the expression evaluation.
  Shale is totally agnostic to such expressions, and does not know whether
  or not they exist.

* "#{xxx}" is a JSF 1.0/1.1 expresion.  At rendering time, it has identical
  syntax and semantics to a corresponding "${xxx}" expression as described
  above.  The difference is that a "#{xxx}" expression also has meaning on
the
  subsequent postback caused by a form submit, when the JSP page that
  originally created this view no longer exists.

Can you clarify which usage of expresion syntax you are referring to?

NOTE:  One of the primary objectives of the JSF 1.2 and JSP 2.1 specs
was to resolve the semantic differences between the "${...}" and
"#{...}" expression syntaxes -- but Shale itself doesn't care anything
about this area.  It's more an issue for the underlying JSP pages and
JSF components that you are using.

Craig


> Thanks,
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: [Shale] What's the deal with the dollar signs?

Posted by Craig McClanahan <cr...@gmail.com>.
On 8/20/05, David G. Friedman <hu...@ix.netcom.com> wrote:
> I thought I'd read some Shale documents a while ago mentioning the purpose
> for the dollar signs in the example use cases but while speed-reading though
> various Shale documents, I'm totally missing that.  Can someone point that
> out to me?
> 

I'm not positive what "dollar signs" you are referring to ... but
there are two delimiters for dynamic expressions that might be of
interest:

* "${xxx}" is typically an expression in the syntax/semantics supported
  by the JSP Standard Tag Library (JSTL), as well as that supported by
  JSP 2.0.  These expressions are evaluated as the page is rendered,
  and are dynamically replaced by the result of the expression evaluation.
  Shale is totally agnostic to such expressions, and does not know whether
  or not they exist.

* "#{xxx}" is a JSF 1.0/1.1 expresion.  At rendering time, it has identical
  syntax and semantics to a corresponding "${xxx}" expression as described
  above.  The difference is that a "#{xxx}" expression also has meaning on the
  subsequent postback caused by a form submit, when the JSP page that
  originally created this view no longer exists.

Can you clarify which usage of expresion syntax you are referring to?

NOTE:  One of the primary objectives of the JSF 1.2 and JSP 2.1 specs
was to resolve the semantic differences between the "${...}" and
"#{...}" expression syntaxes -- but Shale itself doesn't care anything
about this area.  It's more an issue for the underlying JSP pages and
JSF components that you are using.

Craig


> Thanks,
> David
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org