Re: Requirements for skinning module

[Jeanne Waldman]

I was going to add a 'requirement' that is along these lines in that the 
renderer may choose to map a selector from one thing to something else. 
You can look at Trinidad's FileSystemStyleCache for where we do this 
today in Trinidad in a not-very-clean way.
Also, for portlets, we have a styleClassMap where we map a renderer's 
skin selectors to a portlet skin selector, like af|inputText::content - 
portlet-form, for example.


Also, it would be great to have a feature where the skin selectors are 
stored in an xml file that can be read from the renderer and from a tool 
that creates documentation so we have a single source of truth. This 
could be tied into the renderer knowing about its selectors. It is 
possible for selectors to be different from one render kit to another 
because, although we try to keep the names abstract, it really is tied 
to the output (HTML).


We might want 'base' skins to not be tied to a render-kit, but generic 
so that desktop, pda, etc can extend from the base skin. We sort of have 
this in Trinidad because the skin xss file has imports, but it is messy. 
The entire composition/extension will need a lot of thought and use cases.


People have been asking for an API to return the skinning properties 
(css properties, like color: black) given a skinning key.


I know these requirements aren't as general as yours Simon, so maybe 
these are implementation as well.


Jeanne



Simon Lessard wrote, On 12/9/2008 12:36 PM PT:

Hi Andrew,

Strictly speaking it's an implementation detail. However, it's so 
complex that maybe it should get some form of API support as well, not 
sure. Maybe by adding a method to the Skin class like 
Skin.getStyleClasses(UIComponent)? Then some implementations could 
choose to evaluate the tree hierarchy and return a different style 
class depending on it... The implementation would be very complex and 
very linked to the render kit it'd be attached to... this is indeed a 
big one to chew on.



Regards,

~ Simon

On Tue, Dec 9, 2008 at 2:59 PM, Andrew Robinson 
<[EMAIL PROTECTED] > 
wrote:


I am not sure of how feasible this is, but I know one complication of
skinning components rather than styling HTML is that of nesting. In
CSS you can have:

DIV.myclass > SPAN.myclass

to single out a specific parent-child relationship. This is very
powerful as it does not affect all children but only the direct
children. The problem with skinning and components is that this is not
possible to have this type of relationship:

af|borderLayout > af|tree

The reason this is hard is that a component may render many HTML
elements. So af|borderLayout may be on a DIV but have other HTML
elements under that DIV before the tree is begun.

It would be great if this were possible. In order to do it the skin
would have to be made aware of how the renderers render HTML though. I
know this would be a challenge, but if possible I think it would be a
great feature.

This would make things possible like this:

af|panelBorderLayout.darkBackground > af|tree

This is better than:

af|panelBorderLayout.darkBackground af|tree

because it would not break this:

af|borderLayout.lightBackground af|tree

Full theoretical use case:

af|panelBorderLayout.darkBackground {
 background-color: black;
 color: white;
}
af|panelBorderLayout.darkBackground > af|tree {
 color: yellow;
}
af|panelBorderLayout.lightBackground {
 background-color: white;
 color: black;
}
af|panelBorderLayout.darkBackground > af|tree {
 color: gray;
}

This is a very simple use case, but basically there could be times
where it is desirable to skin a direct child component and not all
children components of a type.

Something to chew on...

-Andrew

On Tue, Dec 9, 2008 at 9:41 AM, Simon Lessard
<[EMAIL PROTECTED] > wrote:
> Hi,
>
> This post is to determine the requirements of a common skinning
module for
> MyFaces and potentially for JSF 2.0 if good enough. It's
following the post
> about skinning from the previous days. I'll leave this post
opened for 72
> hours then we'll start designing accordingly, most likely
starting from what
> I proposed in the aforementioned skinning post with some
potential changes
> to fit the requirements we're going to choose.
>
> Paul Rivera proposed the following list:
>
> from trinidad:
>
> basic css style skinning
> global styles/aliases
> skin extensions
> skin additions for custom component developers
> properties skinning
> icon skinning
> text skinning / translations
>
> using bundle-name
> using translation-source
>
> skin variants based on:
>
> agent name
> agent version
> platform name
> accessibility-profile
> directi

[jira] Created: (TOMAHAWK-1379) Type mismatch for property 'expandRoot', for Tag class 'org.apache.myfaces.custom.tree.taglib.TreeTag'

[Lionel Li (JIRA)]

Type mismatch for property 'expandRoot', for Tag class 
'org.apache.myfaces.custom.tree.taglib.TreeTag'
--

 Key: TOMAHAWK-1379
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1379
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tree
Affects Versions: 1.1.8
 Environment: WebLogic81, Tomahawk for JSF1.1
Reporter: Lionel Li


I use Tomahawk for JSF1.1 + SUN JSF 1.1 RI 
My application occur a error when I publish it to WebLogic81, but it's ok in 
Tomcat5.5.
 
Here is the error:

Parsing of JSP File '/test.jsp' failed: 

/test.jsp(5): Error in using tag library 
uri='http://myfaces.apache.org/tomahawk' prefix='t': type mismatch for property 
'expandRoot', for Tag class 'org.apache.myfaces.custom.tree.taglib.TreeTag': 
tld says java.lang.String, implementation type is boolean
probably occurred due to an error in /test.jsp line 5:
<%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t"%> 


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Requirements for skinning module

[Simon Lessard]

Hi Andrew,

Strictly speaking it's an implementation detail. However, it's so complex
that maybe it should get some form of API support as well, not sure. Maybe
by adding a method to the Skin class like Skin.getStyleClasses(UIComponent)?
Then some implementations could choose to evaluate the tree hierarchy and
return a different style class depending on it... The implementation would
be very complex and very linked to the render kit it'd be attached to...
this is indeed a big one to chew on.


Regards,

~ Simon

On Tue, Dec 9, 2008 at 2:59 PM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:

> I am not sure of how feasible this is, but I know one complication of
> skinning components rather than styling HTML is that of nesting. In
> CSS you can have:
>
> DIV.myclass > SPAN.myclass
>
> to single out a specific parent-child relationship. This is very
> powerful as it does not affect all children but only the direct
> children. The problem with skinning and components is that this is not
> possible to have this type of relationship:
>
> af|borderLayout > af|tree
>
> The reason this is hard is that a component may render many HTML
> elements. So af|borderLayout may be on a DIV but have other HTML
> elements under that DIV before the tree is begun.
>
> It would be great if this were possible. In order to do it the skin
> would have to be made aware of how the renderers render HTML though. I
> know this would be a challenge, but if possible I think it would be a
> great feature.
>
> This would make things possible like this:
>
> af|panelBorderLayout.darkBackground > af|tree
>
> This is better than:
>
> af|panelBorderLayout.darkBackground af|tree
>
> because it would not break this:
>
> af|borderLayout.lightBackground af|tree
>
> Full theoretical use case:
>
> af|panelBorderLayout.darkBackground {
>  background-color: black;
>  color: white;
> }
> af|panelBorderLayout.darkBackground > af|tree {
>  color: yellow;
> }
> af|panelBorderLayout.lightBackground {
>  background-color: white;
>  color: black;
> }
> af|panelBorderLayout.darkBackground > af|tree {
>  color: gray;
> }
>
> This is a very simple use case, but basically there could be times
> where it is desirable to skin a direct child component and not all
> children components of a type.
>
> Something to chew on...
>
> -Andrew
>
> On Tue, Dec 9, 2008 at 9:41 AM, Simon Lessard <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> > This post is to determine the requirements of a common skinning module
> for
> > MyFaces and potentially for JSF 2.0 if good enough. It's following the
> post
> > about skinning from the previous days. I'll leave this post opened for 72
> > hours then we'll start designing accordingly, most likely starting from
> what
> > I proposed in the aforementioned skinning post with some potential
> changes
> > to fit the requirements we're going to choose.
> >
> > Paul Rivera proposed the following list:
> >
> > from trinidad:
> >
> > basic css style skinning
> > global styles/aliases
> > skin extensions
> > skin additions for custom component developers
> > properties skinning
> > icon skinning
> > text skinning / translations
> >
> > using bundle-name
> > using translation-source
> >
> > skin variants based on:
> >
> > agent name
> > agent version
> > platform name
> > accessibility-profile
> > direction (:rtl)
> > locale (@locale, :lang) -> Accdg to the skinning guide, this is not yet
> > implemented in trinidad
> >
> > dynamically changing skins at runtime
> > compressed styleclass names feature
> > CHECK_FILE_MODIFICATION feature
> > And as Jeanne mentioned, compatibility with portals.  I don't have much
> > experience with portals.  I will probably need to look more into this.
> >
> > added requirements:
> >
> > tomahawk-support: make use of AddResource and ExtensionsFilter
> > generic-support
> >
> > Personally I disagree quite a lot with that list. Not that those aren't
> nice
> > features, it's just that they're implementation details and not API
> > requirements imho. I would indeed like to see a special implementation
> > support all that, I would just not link them o the base API in any way.
> > Among other thing it expose way too much about the rendering technology
> > being used and nothing about the extensibility requirement that fits JSF
> > architecture. My own list would look like the following. It's a priority
> > list so I believe overdoing a lower requirement at the expense of the
> higher
> > shouldn't be done:
> >
> > The skinning module should
> >
> > Be pluggable like other JSF modules (various handlers)
> > Allow skin composition and extension for maximum reuse and enforce better
> > interoperability between various extensions
> > Allow skin change at runtime
> > Be localizable
> > Leverages existing API (JSF 2.0) whenever possible rather than adding
> extra
> > classes and methods
> > Be independant from the rendering technology used (not necessarily CSS
> for
> > HTML render kit)
> > Allow maximum compatibility with existing sk

Re: [jira] Resolved: (PORTLETBRIDGE-47) BridgeImpl pass PortletConfig instance to FacesContextFactory instead PortletContext

[Scott O'Bryan]

No doubt, I think he's been holding out on us.  :)

Kito Mann wrote:

Busy day, Michael? :-)

On Tue, Dec 9, 2008 at 2:05 PM, Michael Freedman (JIRA) 
mailto:dev@myfaces.apache.org>> wrote:



[

https://issues.apache.org/jira/browse/PORTLETBRIDGE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman resolved PORTLETBRIDGE-47.
---

  Resolution: Fixed
   Fix Version/s: 2.0.0
  1.0.0

bridge has been modified to pass/ really on the PortletContext to
the FacesContextFactory vs the PortletConfig.

> BridgeImpl pass PortletConfig instance to FacesContextFactory
instead PortletContext
>


>
> Key: PORTLETBRIDGE-47
> URL:
https://issues.apache.org/jira/browse/PORTLETBRIDGE-47
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>Affects Versions: 1.0.0-alpha-2
>Reporter: Leonardo Uribe
>Priority: Critical
> Fix For: 1.0.0, 2.0.0
>
>
> On myfaces portlet bridge (for jsf 1.2) do this
(org.apache.myfaces.portlet.faces.bridge.BridgeImpl line 240):
> try
> {
>   // Get the FacesContext instance for this request
>   context =
>  
getFacesContextFactory().getFacesContext(mPortletConfig, request,

response, getLifecycle());
> It should pass a javax.portlet.PortletContext instance instead,
because this is the expected var here.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.




--
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99
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

Re: Requirements for skinning module

[Gerhard Petracek]

+1

regards,
gerhard



2008/12/9 Matthias Wessendorf <[EMAIL PROTECTED]>

> Hi.
>
> On Tue, Dec 9, 2008 at 5:41 PM, Simon Lessard <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> > This post is to determine the requirements of a common skinning module
> for
> > MyFaces and potentially for JSF 2.0 if good enough. It's following the
> post
>
> haven't read the old post #badme
> However, it would be cool if that could end up in JSF 2.0
>
> If we plan something like that (a prototype for JSF2) this should have
> more API character and some of the suggested features could be
> implemented (or not,
> if one of the JSF libs isn't interested, for what ever reason).
>
> > about skinning from the previous days. I'll leave this post opened for 72
> > hours then we'll start designing accordingly, most likely starting from
> what
> > I proposed in the aforementioned skinning post with some potential
> changes
> > to fit the requirements we're going to choose.
> >
> > Paul Rivera proposed the following list:
> >
> > from trinidad:
> >
> > basic css style skinning
> > global styles/aliases
> > skin extensions
> > skin additions for custom component developers
> > properties skinning
> > icon skinning
> > text skinning / translations
> >
> > using bundle-name
> > using translation-source
> >
> > skin variants based on:
> >
> > agent name
> > agent version
> > platform name
> > accessibility-profile
> > direction (:rtl)
> > locale (@locale, :lang) -> Accdg to the skinning guide, this is not yet
> > implemented in trinidad
> >
> > dynamically changing skins at runtime
> > compressed styleclass names feature
> > CHECK_FILE_MODIFICATION feature
> > And as Jeanne mentioned, compatibility with portals.  I don't have much
> > experience with portals.  I will probably need to look more into this.
> >
> > added requirements:
> >
> > tomahawk-support: make use of AddResource and ExtensionsFilter
> > generic-support
> >
> > Personally I disagree quite a lot with that list. Not that those aren't
> nice
> > features, it's just that they're implementation details and not API
> > requirements imho. I would indeed like to see a special implementation
>
> +1 I agree here. I like the idea of a more general API.
>
> > support all that, I would just not link them o the base API in any way.
> > Among other thing it expose way too much about the rendering technology
> > being used and nothing about the extensibility requirement that fits JSF
> > architecture. My own list would look like the following. It's a priority
>
> +1 making it flexible sounds great.
>
> > list so I believe overdoing a lower requirement at the expense of the
> higher
> > shouldn't be done:
> >
> > The skinning module should
> >
> > Be pluggable like other JSF modules (various handlers)
> > Allow skin composition and extension for maximum reuse and enforce better
> > interoperability between various extensions
> > Allow skin change at runtime
> > Be localizable
> > Leverages existing API (JSF 2.0) whenever possible rather than adding
> extra
> > classes and methods
> > Be independant from the rendering technology used (not necessarily CSS
> for
> > HTML render kit)
> > Allow maximum compatibility with existing skin/theme modules (Trinidad,
> > IceFaces, Richfaces), not necessarily by providing direct support for
> those
> > feature but by allowing extension to implement those features using the
> > module's API
> > Be fast, the module shouldn't induce an inherent performance overhaul
> >
> > My list is way more general, but you can place some of what Paul
> mentioned
> > in one of them so here's Paul list again but with what requirement it
> would
>
> I like your approach of a more general API based apporach that is
> flexible as well.
> We could more easily sell this API set to the RI folks (EG guys) and
> our libs could
> "just" jump in, easily.
>
> This would be better instead of implementing a *large* overall, one
> size-all fit skinning
> for our libs. It also would be bad if that wouldn't be compliant to a
> JSF skinning (not sure
> if that is included)
>
> Thanks for putting this mail together.
>
> -Matthias
>
> > fall in in my list. The elements in green are covered by the
> requirements,
> > those in red are implementation detail that shouldn't be required for all
> > implementation and the skin's general contract. Elements in blue are
> those
> > that should have a requirement but currently don't because I don't know
> how
> > to put them down or if they really should be requirement and finally,
> > elements in orange are relevant but that I didn't consider in my proposed
> > API (which is a problem):
> >
> > from trinidad:
> >
> > basic css style skinning (implementation detail, not a hard requirement)
> > global styles/aliases (implementation detail, not a hard requirement)
> > skin extensions (REQ 2 through extension)
> > skin additions for custom component developers (REQ 2 through
> composition)
> > properties skinning (Not currently a requirement)
> > icon skin

Re: [jira] Resolved: (PORTLETBRIDGE-47) BridgeImpl pass PortletConfig instance to FacesContextFactory instead PortletContext

[Kito Mann]

Busy day, Michael? :-)

On Tue, Dec 9, 2008 at 2:05 PM, Michael Freedman (JIRA) <
dev@myfaces.apache.org> wrote:

>
> [
> https://issues.apache.org/jira/browse/PORTLETBRIDGE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Michael Freedman resolved PORTLETBRIDGE-47.
> ---
>
>   Resolution: Fixed
>Fix Version/s: 2.0.0
>   1.0.0
>
> bridge has been modified to pass/ really on the PortletContext to the
> FacesContextFactory vs the PortletConfig.
>
> > BridgeImpl pass PortletConfig instance to FacesContextFactory instead
> PortletContext
> >
> 
> >
> > Key: PORTLETBRIDGE-47
> > URL:
> https://issues.apache.org/jira/browse/PORTLETBRIDGE-47
> > Project: MyFaces Portlet Bridge
> >  Issue Type: Bug
> >Affects Versions: 1.0.0-alpha-2
> >Reporter: Leonardo Uribe
> >Priority: Critical
> > Fix For: 1.0.0, 2.0.0
> >
> >
> > On myfaces portlet bridge (for jsf 1.2) do this
> (org.apache.myfaces.portlet.faces.bridge.BridgeImpl line 240):
> > try
> > {
> >   // Get the FacesContext instance for this request
> >   context =
> >   getFacesContextFactory().getFacesContext(mPortletConfig,
> request, response, getLifecycle());
> > It should pass a javax.portlet.PortletContext instance instead, because
> this is the expected var here.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>


-- 
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99
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

Re: Requirements for skinning module

[Matthias Wessendorf]

Hi.

On Tue, Dec 9, 2008 at 5:41 PM, Simon Lessard <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This post is to determine the requirements of a common skinning module for
> MyFaces and potentially for JSF 2.0 if good enough. It's following the post

haven't read the old post #badme
However, it would be cool if that could end up in JSF 2.0

If we plan something like that (a prototype for JSF2) this should have
more API character and some of the suggested features could be
implemented (or not,
if one of the JSF libs isn't interested, for what ever reason).

> about skinning from the previous days. I'll leave this post opened for 72
> hours then we'll start designing accordingly, most likely starting from what
> I proposed in the aforementioned skinning post with some potential changes
> to fit the requirements we're going to choose.
>
> Paul Rivera proposed the following list:
>
> from trinidad:
>
> basic css style skinning
> global styles/aliases
> skin extensions
> skin additions for custom component developers
> properties skinning
> icon skinning
> text skinning / translations
>
> using bundle-name
> using translation-source
>
> skin variants based on:
>
> agent name
> agent version
> platform name
> accessibility-profile
> direction (:rtl)
> locale (@locale, :lang) -> Accdg to the skinning guide, this is not yet
> implemented in trinidad
>
> dynamically changing skins at runtime
> compressed styleclass names feature
> CHECK_FILE_MODIFICATION feature
> And as Jeanne mentioned, compatibility with portals.  I don't have much
> experience with portals.  I will probably need to look more into this.
>
> added requirements:
>
> tomahawk-support: make use of AddResource and ExtensionsFilter
> generic-support
>
> Personally I disagree quite a lot with that list. Not that those aren't nice
> features, it's just that they're implementation details and not API
> requirements imho. I would indeed like to see a special implementation

+1 I agree here. I like the idea of a more general API.

> support all that, I would just not link them o the base API in any way.
> Among other thing it expose way too much about the rendering technology
> being used and nothing about the extensibility requirement that fits JSF
> architecture. My own list would look like the following. It's a priority

+1 making it flexible sounds great.

> list so I believe overdoing a lower requirement at the expense of the higher
> shouldn't be done:
>
> The skinning module should
>
> Be pluggable like other JSF modules (various handlers)
> Allow skin composition and extension for maximum reuse and enforce better
> interoperability between various extensions
> Allow skin change at runtime
> Be localizable
> Leverages existing API (JSF 2.0) whenever possible rather than adding extra
> classes and methods
> Be independant from the rendering technology used (not necessarily CSS for
> HTML render kit)
> Allow maximum compatibility with existing skin/theme modules (Trinidad,
> IceFaces, Richfaces), not necessarily by providing direct support for those
> feature but by allowing extension to implement those features using the
> module's API
> Be fast, the module shouldn't induce an inherent performance overhaul
>
> My list is way more general, but you can place some of what Paul mentioned
> in one of them so here's Paul list again but with what requirement it would

I like your approach of a more general API based apporach that is
flexible as well.
We could more easily sell this API set to the RI folks (EG guys) and
our libs could
"just" jump in, easily.

This would be better instead of implementing a *large* overall, one
size-all fit skinning
for our libs. It also would be bad if that wouldn't be compliant to a
JSF skinning (not sure
if that is included)

Thanks for putting this mail together.

-Matthias

> fall in in my list. The elements in green are covered by the requirements,
> those in red are implementation detail that shouldn't be required for all
> implementation and the skin's general contract. Elements in blue are those
> that should have a requirement but currently don't because I don't know how
> to put them down or if they really should be requirement and finally,
> elements in orange are relevant but that I didn't consider in my proposed
> API (which is a problem):
>
> from trinidad:
>
> basic css style skinning (implementation detail, not a hard requirement)
> global styles/aliases (implementation detail, not a hard requirement)
> skin extensions (REQ 2 through extension)
> skin additions for custom component developers (REQ 2 through composition)
> properties skinning (Not currently a requirement)
> icon skinning (Not currently a requirement)
> text skinning / translations (REQ 4)
>
> using bundle-name
> using translation-source
>
> skin variants based on: (implementation detail, not a hard requirement,
> could be implemented at RenderKit level, Factory level or loader level with
> what I proposed)
>
> agent name
> agent version
> platform name
>

Re: Requirements for skinning module

[Andrew Robinson]

I am not sure of how feasible this is, but I know one complication of
skinning components rather than styling HTML is that of nesting. In
CSS you can have:

DIV.myclass > SPAN.myclass

to single out a specific parent-child relationship. This is very
powerful as it does not affect all children but only the direct
children. The problem with skinning and components is that this is not
possible to have this type of relationship:

af|borderLayout > af|tree

The reason this is hard is that a component may render many HTML
elements. So af|borderLayout may be on a DIV but have other HTML
elements under that DIV before the tree is begun.

It would be great if this were possible. In order to do it the skin
would have to be made aware of how the renderers render HTML though. I
know this would be a challenge, but if possible I think it would be a
great feature.

This would make things possible like this:

af|panelBorderLayout.darkBackground > af|tree

This is better than:

af|panelBorderLayout.darkBackground af|tree

because it would not break this:

af|borderLayout.lightBackground af|tree

Full theoretical use case:

af|panelBorderLayout.darkBackground {
  background-color: black;
  color: white;
}
af|panelBorderLayout.darkBackground > af|tree {
  color: yellow;
}
af|panelBorderLayout.lightBackground {
  background-color: white;
  color: black;
}
af|panelBorderLayout.darkBackground > af|tree {
  color: gray;
}

This is a very simple use case, but basically there could be times
where it is desirable to skin a direct child component and not all
children components of a type.

Something to chew on...

-Andrew

On Tue, Dec 9, 2008 at 9:41 AM, Simon Lessard <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This post is to determine the requirements of a common skinning module for
> MyFaces and potentially for JSF 2.0 if good enough. It's following the post
> about skinning from the previous days. I'll leave this post opened for 72
> hours then we'll start designing accordingly, most likely starting from what
> I proposed in the aforementioned skinning post with some potential changes
> to fit the requirements we're going to choose.
>
> Paul Rivera proposed the following list:
>
> from trinidad:
>
> basic css style skinning
> global styles/aliases
> skin extensions
> skin additions for custom component developers
> properties skinning
> icon skinning
> text skinning / translations
>
> using bundle-name
> using translation-source
>
> skin variants based on:
>
> agent name
> agent version
> platform name
> accessibility-profile
> direction (:rtl)
> locale (@locale, :lang) -> Accdg to the skinning guide, this is not yet
> implemented in trinidad
>
> dynamically changing skins at runtime
> compressed styleclass names feature
> CHECK_FILE_MODIFICATION feature
> And as Jeanne mentioned, compatibility with portals.  I don't have much
> experience with portals.  I will probably need to look more into this.
>
> added requirements:
>
> tomahawk-support: make use of AddResource and ExtensionsFilter
> generic-support
>
> Personally I disagree quite a lot with that list. Not that those aren't nice
> features, it's just that they're implementation details and not API
> requirements imho. I would indeed like to see a special implementation
> support all that, I would just not link them o the base API in any way.
> Among other thing it expose way too much about the rendering technology
> being used and nothing about the extensibility requirement that fits JSF
> architecture. My own list would look like the following. It's a priority
> list so I believe overdoing a lower requirement at the expense of the higher
> shouldn't be done:
>
> The skinning module should
>
> Be pluggable like other JSF modules (various handlers)
> Allow skin composition and extension for maximum reuse and enforce better
> interoperability between various extensions
> Allow skin change at runtime
> Be localizable
> Leverages existing API (JSF 2.0) whenever possible rather than adding extra
> classes and methods
> Be independant from the rendering technology used (not necessarily CSS for
> HTML render kit)
> Allow maximum compatibility with existing skin/theme modules (Trinidad,
> IceFaces, Richfaces), not necessarily by providing direct support for those
> feature but by allowing extension to implement those features using the
> module's API
> Be fast, the module shouldn't induce an inherent performance overhaul
>
> My list is way more general, but you can place some of what Paul mentioned
> in one of them so here's Paul list again but with what requirement it would
> fall in in my list. The elements in green are covered by the requirements,
> those in red are implementation detail that shouldn't be required for all
> implementation and the skin's general contract. Elements in blue are those
> that should have a requirement but currently don't because I don't know how
> to put them down or if they really should be requirement and finally,
> elements in orange are relevant but th

[jira] Resolved: (PORTLETBRIDGE-37) VIEWSTATE_PARAM parsing in StateManager doesn't always work

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-37.
---

   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

As per previous comment. I have now merged this code from the 1.0 code line to 
the 2.0 codeline so bug is fixed in both versions.

> VIEWSTATE_PARAM parsing in StateManager doesn't always work
> ---
>
> Key: PORTLETBRIDGE-37
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-37
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>  Components: Impl
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Michael Freedman
>Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
>
> Currently the code that parses for the VIEWSTATE_PARAM in the Bridge's 
> StateManager is rudimentary (primarily for performance reasons).  If checks 
> to see if there is a closing /> to ensure it doesn't read beyond the end of 
> the tag.  However some environment (Trinidad) close the element just with a 
> '>'.  When this check fails we return null meaning the parameter isn't 
> located/preserved.  State is lost by the bridge.  The bridge should be more 
> tolerant.  At a minimum it should recognize either end of tag.  But failing 
> this and other checks it should do more extensive parsing to ensure proper 
> execution -- i.e. it should work regardless of whether the name field is 
> before the value field and/or '>' is a character in the view state param's 
> value.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-40) Redirect during render doesn't refresh properly

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-40.
---

   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

As per previous comment. I have now merged this code from the 1.0 code line to 
the 2.0 codeline so bug is fixed in both versions.

> Redirect during render doesn't refresh properly
> ---
>
> Key: PORTLETBRIDGE-40
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-40
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>  Components: Impl
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Michael Freedman
>Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
>
> The redirect during render support doesn't retain the redirect URL across 
> requests.  If a user refreshes the portlet the original (before redirect) url 
> is targeted.  Though this results in the redirect replaying this doesn't 
> always yield identical results than if you targeted the redirect url 
> directly. This is because Faces (extensions) may encode additional state/info 
> in the query string of the redirect url which changes each time such a 
> redirect would be issued.  To function properly the bridge must cache the 
> redirect url, and detect that it should use it on subsequent refreshes 
> (renders prior to action) instead of causing the redirect logic to be 
> triggered all over again.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-38) Messages not maintained in insertion order as per JSF 1.2 spec

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-38.
---

   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

As per previous comment. I have now merged this code from the 1.0 code line to 
the 2.0 codeline so bug is fixed in both versions.

> Messages not maintained in insertion order as per JSF 1.2 spec
> --
>
> Key: PORTLETBRIDGE-38
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-38
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>  Components: Impl
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Michael Freedman
>Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
>
> The Bridge isn't preserving messages in insertion order as per the 1.2 JSF 
> spec.  To fix this the PortletFacesContextImpl should switch from using a 
> HashMap to a LinkedHashMap.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-41) EncodeActionURL doesn't encode valid nonFaces targets

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-41.
---

   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

As per previous comment. I have now merged this code from the 1.0 code line to 
the 2.0 codeline so bug is fixed in both versions.

> EncodeActionURL doesn't encode valid nonFaces targets
> -
>
> Key: PORTLETBRIDGE-41
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-41
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>  Components: Impl
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Michael Freedman
>Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
>
> Faces allows one to construct an action URL (navigation) to a nonFaces 
> target.  However the bridges (ExternalContext) encodeActionURL only 
> recognizes and encodes Faces targets.  What it should do when it encounters a 
> nonFaces target (within the web app) is encode it distinctly from a Faces 
> target as a portlet renderURL.  The bridge on receiving such a render request 
> should recognize the nonFaces target and do an immediate dispatch rather then 
> processing the request through Faces (lifecycle).  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-42) Bridge not excluding bridge request attributes from its request scope

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-42.
---

   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

As per previous comment. I have now merged this code from the 1.0 code line to 
the 2.0 codeline so bug is fixed in both versions.

> Bridge not excluding bridge request attributes from its request scope
> -
>
> Key: PORTLETBRIDGE-42
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-42
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>  Components: Impl
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Michael Freedman
>Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
>
> The bridge is supposed to exclude from its managed request scope those 
> attributes it creates/uses but doesn't need across a portlet request.  
> Currently, these aren't being excluded.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-43) MyFaces action handling sometimes fails with exception from ExternalContext setRequestCharacterSetEncoding

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-43.
---

   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

As per previous comment. I have now merged this code from the 1.0 code line to 
the 2.0 codeline so bug is fixed in both versions.  See description for general 
info on fix.

> MyFaces action handling sometimes fails with exception from ExternalContext 
> setRequestCharacterSetEncoding
> --
>
> Key: PORTLETBRIDGE-43
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-43
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>  Components: Impl
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Michael Freedman
>Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
>
> In some configurations (noteably when Facelets is used), an exception is 
> thrown when MyFaces tries to set the request character encoding during an 
> action.  The exception claims that the request (parameters) have already been 
> read and hence one can't do this set.  This occurs because the Bridge reads 
> the request parameters during ExternalContext construction to determine the 
> view target of the request (if encodes this target in a render parameter).  
> Fix is to delay determining the view until Faces actually tries to determine 
> it itself.  I.e. Don't resolve the view until either EC.getRequestPathInfo or 
> EC.getRequestServletPath are called.  Note: because at least older version of 
> the Faces RI we support don't call these (in the portlet case) but rather 
> relies on a request attribute being set -- the bridge must also 
> detect/resolve the view for this case as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-44) Implement Revision 15 support for nonFaces targets

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-44.
---

   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

As per previous comment.  I have now merged this code from the 1.0 code line to 
the 2.0 codeline so bug is fixed in both versions.  

> Implement Revision 15 support for nonFaces targets
> --
>
> Key: PORTLETBRIDGE-44
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-44
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>  Components: Impl
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Michael Freedman
>Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
>
> Current implementation doesn't properly/fully support navigating to nonFaces 
> views (and back again).  Implement this support as described in revision 15 
> of the specification.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-45) Phase (Action or Render) request attribute is removed prior to releasing the Faces context

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-45.
---

   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

Reversed code so that the attribute is now removed after the FacesContext is 
destroyed.

> Phase (Action or Render) request attribute is removed prior to releasing the 
> Faces context
> --
>
> Key: PORTLETBRIDGE-45
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-45
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>  Components: Impl
>Affects Versions: 1.0.0-alpha-2
>Reporter: Lei Oh
> Fix For: 1.0.0, 2.0.0
>
>
> In doFacesRequest() in BridgeImpl, the bridge removes the 
> PORTLET_LIFECYCLE_PHASE attribute from the request prior to calling 
> FacesContext.release(). This prevents decorators from accessing this 
> attribute (eg, ExternalContext). We need to switch this order.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-46) portlet.xml in Portlet Bridge demo WAR is not JSR 168 conform

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-46.
---

   Resolution: Fixed
Fix Version/s: 1.0.0

portlet.xml updated

> portlet.xml in Portlet Bridge demo WAR is not JSR 168 conform
> -
>
> Key: PORTLETBRIDGE-46
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-46
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>Affects Versions: 1.0.0-alpha-2
>Reporter: Stefan Hepper
> Fix For: 1.0.0
>
>
> The portlet.xml contains a description and name tag with an lang attribute, 
> however, in order to be correct it should be an xml:lang attribute.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (PORTLETBRIDGE-47) BridgeImpl pass PortletConfig instance to FacesContextFactory instead PortletContext

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-47.
---

   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0

bridge has been modified to pass/ really on the PortletContext to the 
FacesContextFactory vs the PortletConfig.

> BridgeImpl pass PortletConfig instance to FacesContextFactory instead 
> PortletContext
> 
>
> Key: PORTLETBRIDGE-47
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-47
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>Affects Versions: 1.0.0-alpha-2
>Reporter: Leonardo Uribe
>Priority: Critical
> Fix For: 1.0.0, 2.0.0
>
>
> On myfaces portlet bridge (for jsf 1.2) do this 
> (org.apache.myfaces.portlet.faces.bridge.BridgeImpl line 240):
> try
> {
>   // Get the FacesContext instance for this request
>   context =
>   getFacesContextFactory().getFacesContext(mPortletConfig, request, 
> response, getLifecycle());
> It should pass a javax.portlet.PortletContext instance instead, because this 
> is the expected var here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (PORTLETBRIDGE-50) Should Bridge use Lifecycle to RestoreView when restoring from memory cache?

[Michael Freedman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman updated PORTLETBRIDGE-50:
--

   Resolution: Fixed
Fix Version/s: 2.0.0
   1.0.0
   Status: Resolved  (was: Patch Available)

As per changed spec, though the bridge continues to cache the view after the 
action the restoration of this cache is now done via the Lifecyle (brdige's 
viewhandler).

> Should Bridge use Lifecycle to RestoreView when restoring from memory cache?
> 
>
> Key: PORTLETBRIDGE-50
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-50
> Project: MyFaces Portlet Bridge
>  Issue Type: Bug
>  Components: Impl
>Affects Versions: 2.0.0
>Reporter: Michael Freedman
>Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
> Attachments: jira_50.patch
>
>
> Currently the bridge manually restores the view in the first render after an 
> action from memory (because the action can't save the view via faces).  By 
> manual I mean it merely sets the viewRoot to the view instead of calling 
> Lifecycle.execute.  This means the before/after restoreView phase listeners 
> aren't called.  About six months ago we added a hack to the spec/impl to 
> require the before listener be called but withheld the after worried that 
> running it twice in situation where action/render is usually in a single 
> lifecycle could introduce problems.  Well we hit use case where either 
> neither of the two or both must be called but not one without the other 
> (Faces demands this behavior).  
> In discussing this it was raised that maybe we shouldn't have this manual 
> process at all -- instead restore the view from memory when necessary as a 
> natural part of the RestoreView phase of executing the lifecycle.  
> We decided we should try this and determine if there are any side effects.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: JavaDoc and checkstyle

[Gerhard Petracek]

hi,

that's right - since it was a pretty long thread which also includes other
topics, i just linked the first message as a starting point.
anyway, does someone know a nice and correct wiki about such topics? so we
could link it in our wiki.

regards,
gerhard



2008/12/9 Simon Lessard <[EMAIL PROTECTED]>

> Hi Simon,
>
> Gerhard link is correct although not including the whole post, one of the
> reply from Matthias. Maybe we should raise the issue on legal-discuss? At
> worst, your way of writing the doc sounds very reasonable as well. My team
> wouldn't need the go away for a while part however since it's two completely
> different persons coding and documenting for code reviews purpose.
>
>
> Regards,
>
> ~ Simon
>
>
> On Tue, Dec 9, 2008 at 12:23 PM, Simon Kitching <[EMAIL PROTECTED]>wrote:
>
>> Hi,
>>
>> I doubt very much that simply retyping javadoc from the spec is legally
>> sufficient to permit non-Aapache-licensed text to be included in an
>> Apache-licensed file.
>>
>> Note that I was *asking* whether copying was allowed; hopefully there is
>> something in the spec licenses that *does* permit it. But if not, then
>> we must follow the relevant copyright laws. I definitely interpreted the
>> original JSF1.1/JSF1.2 specs as NOT permitting copying of javadoc from
>> the spec into our classes.
>>
>> Do you happen to have a link (or even the email subject line) for the
>> earlier discussion? I must have missed that...
>>
>> Note that for dtd and schema files it is pretty easy to avoid copyright
>> issues; the vast majority of such files is data-structure definition
>> that has only one possible form, and therefore is not copyrightable.
>> Simply taking someone else's file is still wrong here, but the original
>> can be used as a "reference" for the non-copyrightable technical
>> details, so creating the new version is effectively pretty close to
>> "just retyping".
>>
>> Javadoc, however, is prose writing which is creative expression. So it
>> should *not* be used as a reference when writing new javadoc; that would
>> be plagiarism.
>>
>> I did create a significant amount of javadoc for the JSF1.1 and JSF1.2
>> implementations (though still far from complete coverage); my approach
>> was to
>> (a) ensure that the implementation matched the specification description
>> (referencing the original docs)
>> (b) go away for a while
>> (c) some time later, write the javadoc based on the *code* (not using
>> the original docs as a reference)
>>
>> From your other email:
>> 
>> p.s. I know that 1.1 and 1.2 don't have any JavaDoc copied, actually it
>> only refer to the official one online which isn't very useful for
>> offline users nor those working directly looking at the code. Keeping
>> JavaDoc out is of course a valid option as well if the community wishes
>> it, but it also implies our Maven generated JavaDoc for the site won't
>> be any good.
>> 
>>
>> I think the javadoc that was specifically written for myfaces classes is
>> more useful for end-users than the spec stuff (more helpful, less picky
>> technical detail). But yes it is a minority of classes, with most still
>> just linking to the external specs. I'm sure nobody *wants* to keep
>> javadoc external to the classes, but recreating all the docs is a big
>> task, and the alternative (copying) was IMO just not legal.
>>
>> Yes, it's annoying but copyright is copyright. And if we don't follow
>> the law then the spec copyright-holder has every right to sue.
>>
>> IANAL and all that.
>>
>> Regards,
>> Simon K.
>>
>> Simon Lessard schrieb:
>> > Hi Simon K.,
>> >
>> > We had that discussion not long ago on another post. We're actually
>> > retyping the whole thing, but mimicking the official JavaDoc. Since
>> > it's not copied directly it seems it's allowed.
>> >
>> > ~ Simon
>> >
>> > On Tue, Dec 9, 2008 at 10:06 AM, Simon Kitching <[EMAIL PROTECTED]
>> > > wrote:
>> >
>> > Hmm..by the way, are you copying-and-pasting the JSF javadoc into
>> > myfaces classes? If so, are you sure that this is allowed? Javadoc
>> > descriptions would definitely be copyrightable, so explicit
>> permission
>> > would be needed to place text released under the CDDL into a file
>> > licensed under the Apache license...
>> >
>> > In Myfaces core 1.1 and 1.2 releases we have been careful to NOT
>> copy
>> > any javadoc from the spec..
>> >
>> > Regards,
>> > Simon
>> >
>> > >> Simon Lessard wrote:
>> > >>
>> > >>> To be more precise checkstyle whines about missing @param and
>> > @return,
>> > >>> which
>> > >>> is theoretically nice. However, JSF's JavaDoc is broken and
>> > doesn't
>> > >>> specifies those most of the time, so the question is is it
>> > better to match
>> > >>> the official API or to make checkstyle happy?
>> > >>>
>> > >>> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
>> > >>> <[EMAIL PROTECTED]
>> > >wrote:
>

Re: JavaDoc and checkstyle

[Simon Lessard]

Hi Simon,

Gerhard link is correct although not including the whole post, one of the
reply from Matthias. Maybe we should raise the issue on legal-discuss? At
worst, your way of writing the doc sounds very reasonable as well. My team
wouldn't need the go away for a while part however since it's two completely
different persons coding and documenting for code reviews purpose.


Regards,

~ Simon

On Tue, Dec 9, 2008 at 12:23 PM, Simon Kitching <[EMAIL PROTECTED]>wrote:

> Hi,
>
> I doubt very much that simply retyping javadoc from the spec is legally
> sufficient to permit non-Aapache-licensed text to be included in an
> Apache-licensed file.
>
> Note that I was *asking* whether copying was allowed; hopefully there is
> something in the spec licenses that *does* permit it. But if not, then
> we must follow the relevant copyright laws. I definitely interpreted the
> original JSF1.1/JSF1.2 specs as NOT permitting copying of javadoc from
> the spec into our classes.
>
> Do you happen to have a link (or even the email subject line) for the
> earlier discussion? I must have missed that...
>
> Note that for dtd and schema files it is pretty easy to avoid copyright
> issues; the vast majority of such files is data-structure definition
> that has only one possible form, and therefore is not copyrightable.
> Simply taking someone else's file is still wrong here, but the original
> can be used as a "reference" for the non-copyrightable technical
> details, so creating the new version is effectively pretty close to
> "just retyping".
>
> Javadoc, however, is prose writing which is creative expression. So it
> should *not* be used as a reference when writing new javadoc; that would
> be plagiarism.
>
> I did create a significant amount of javadoc for the JSF1.1 and JSF1.2
> implementations (though still far from complete coverage); my approach
> was to
> (a) ensure that the implementation matched the specification description
> (referencing the original docs)
> (b) go away for a while
> (c) some time later, write the javadoc based on the *code* (not using
> the original docs as a reference)
>
> From your other email:
> 
> p.s. I know that 1.1 and 1.2 don't have any JavaDoc copied, actually it
> only refer to the official one online which isn't very useful for
> offline users nor those working directly looking at the code. Keeping
> JavaDoc out is of course a valid option as well if the community wishes
> it, but it also implies our Maven generated JavaDoc for the site won't
> be any good.
> 
>
> I think the javadoc that was specifically written for myfaces classes is
> more useful for end-users than the spec stuff (more helpful, less picky
> technical detail). But yes it is a minority of classes, with most still
> just linking to the external specs. I'm sure nobody *wants* to keep
> javadoc external to the classes, but recreating all the docs is a big
> task, and the alternative (copying) was IMO just not legal.
>
> Yes, it's annoying but copyright is copyright. And if we don't follow
> the law then the spec copyright-holder has every right to sue.
>
> IANAL and all that.
>
> Regards,
> Simon K.
>
> Simon Lessard schrieb:
> > Hi Simon K.,
> >
> > We had that discussion not long ago on another post. We're actually
> > retyping the whole thing, but mimicking the official JavaDoc. Since
> > it's not copied directly it seems it's allowed.
> >
> > ~ Simon
> >
> > On Tue, Dec 9, 2008 at 10:06 AM, Simon Kitching <[EMAIL PROTECTED]
> > > wrote:
> >
> > Hmm..by the way, are you copying-and-pasting the JSF javadoc into
> > myfaces classes? If so, are you sure that this is allowed? Javadoc
> > descriptions would definitely be copyrightable, so explicit
> permission
> > would be needed to place text released under the CDDL into a file
> > licensed under the Apache license...
> >
> > In Myfaces core 1.1 and 1.2 releases we have been careful to NOT copy
> > any javadoc from the spec..
> >
> > Regards,
> > Simon
> >
> > >> Simon Lessard wrote:
> > >>
> > >>> To be more precise checkstyle whines about missing @param and
> > @return,
> > >>> which
> > >>> is theoretically nice. However, JSF's JavaDoc is broken and
> > doesn't
> > >>> specifies those most of the time, so the question is is it
> > better to match
> > >>> the official API or to make checkstyle happy?
> > >>>
> > >>> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
> > >>> <[EMAIL PROTECTED]
> > >wrote:
> > >>>
> > >>>
> >  Hi all,
> > 
> >  It seems that checkstyle doesn't like JSF's official JavaDoc.
> > Personally
> >  I
> >  would give higher priority to completed comments than
> > checkstyle whining,
> >  what you guys think about it?
> > 
> > 
> >
> >
>
>

Re: JavaDoc and checkstyle

[Simon Kitching]

Hi,

I doubt very much that simply retyping javadoc from the spec is legally
sufficient to permit non-Aapache-licensed text to be included in an
Apache-licensed file.

Note that I was *asking* whether copying was allowed; hopefully there is
something in the spec licenses that *does* permit it. But if not, then
we must follow the relevant copyright laws. I definitely interpreted the
original JSF1.1/JSF1.2 specs as NOT permitting copying of javadoc from
the spec into our classes.

Do you happen to have a link (or even the email subject line) for the
earlier discussion? I must have missed that...

Note that for dtd and schema files it is pretty easy to avoid copyright
issues; the vast majority of such files is data-structure definition
that has only one possible form, and therefore is not copyrightable.
Simply taking someone else's file is still wrong here, but the original
can be used as a "reference" for the non-copyrightable technical
details, so creating the new version is effectively pretty close to
"just retyping".

Javadoc, however, is prose writing which is creative expression. So it
should *not* be used as a reference when writing new javadoc; that would
be plagiarism.

I did create a significant amount of javadoc for the JSF1.1 and JSF1.2
implementations (though still far from complete coverage); my approach
was to
(a) ensure that the implementation matched the specification description
(referencing the original docs)
(b) go away for a while
(c) some time later, write the javadoc based on the *code* (not using
the original docs as a reference)

>From your other email:

p.s. I know that 1.1 and 1.2 don't have any JavaDoc copied, actually it
only refer to the official one online which isn't very useful for
offline users nor those working directly looking at the code. Keeping
JavaDoc out is of course a valid option as well if the community wishes
it, but it also implies our Maven generated JavaDoc for the site won't
be any good.


I think the javadoc that was specifically written for myfaces classes is
more useful for end-users than the spec stuff (more helpful, less picky
technical detail). But yes it is a minority of classes, with most still
just linking to the external specs. I'm sure nobody *wants* to keep
javadoc external to the classes, but recreating all the docs is a big
task, and the alternative (copying) was IMO just not legal.

Yes, it's annoying but copyright is copyright. And if we don't follow
the law then the spec copyright-holder has every right to sue.

IANAL and all that.

Regards,
Simon K.

Simon Lessard schrieb:
> Hi Simon K.,
>
> We had that discussion not long ago on another post. We're actually
> retyping the whole thing, but mimicking the official JavaDoc. Since
> it's not copied directly it seems it's allowed.
>
> ~ Simon
>
> On Tue, Dec 9, 2008 at 10:06 AM, Simon Kitching <[EMAIL PROTECTED]
> > wrote:
>
> Hmm..by the way, are you copying-and-pasting the JSF javadoc into
> myfaces classes? If so, are you sure that this is allowed? Javadoc
> descriptions would definitely be copyrightable, so explicit permission
> would be needed to place text released under the CDDL into a file
> licensed under the Apache license...
>
> In Myfaces core 1.1 and 1.2 releases we have been careful to NOT copy
> any javadoc from the spec..
>
> Regards,
> Simon
>
> >> Simon Lessard wrote:
> >>
> >>> To be more precise checkstyle whines about missing @param and
> @return,
> >>> which
> >>> is theoretically nice. However, JSF's JavaDoc is broken and
> doesn't
> >>> specifies those most of the time, so the question is is it
> better to match
> >>> the official API or to make checkstyle happy?
> >>>
> >>> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
> >>> <[EMAIL PROTECTED]
> >wrote:
> >>>
> >>>
>  Hi all,
> 
>  It seems that checkstyle doesn't like JSF's official JavaDoc.
> Personally
>  I
>  would give higher priority to completed comments than
> checkstyle whining,
>  what you guys think about it?
> 
> 
>
>

Re: JavaDoc and checkstyle

[Simon Lessard]

p.s. I know that 1.1 and 1.2 don't have any JavaDoc copied, actually it only
refer to the official one online which isn't very useful for offline users
nor those working directly looking at the code. Keeping JavaDoc out is of
course a valid option as well if the community wishes it, but it also
implies our Maven generated JavaDoc for the site won't be any good.

Regards,

~ Simon

On Tue, Dec 9, 2008 at 10:06 AM, Simon Kitching <[EMAIL PROTECTED]>wrote:

> Hmm..by the way, are you copying-and-pasting the JSF javadoc into
> myfaces classes? If so, are you sure that this is allowed? Javadoc
> descriptions would definitely be copyrightable, so explicit permission
> would be needed to place text released under the CDDL into a file
> licensed under the Apache license...
>
> In Myfaces core 1.1 and 1.2 releases we have been careful to NOT copy
> any javadoc from the spec..
>
> Regards,
> Simon
>
> >> Simon Lessard wrote:
> >>
> >>> To be more precise checkstyle whines about missing @param and @return,
> >>> which
> >>> is theoretically nice. However, JSF's JavaDoc is broken and doesn't
> >>> specifies those most of the time, so the question is is it better to
> match
> >>> the official API or to make checkstyle happy?
> >>>
> >>> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
> >>> <[EMAIL PROTECTED]>wrote:
> >>>
> >>>
>  Hi all,
> 
>  It seems that checkstyle doesn't like JSF's official JavaDoc.
> Personally
>  I
>  would give higher priority to completed comments than checkstyle
> whining,
>  what you guys think about it?
> 
> 
>
>

Re: JavaDoc and checkstyle

[Simon Lessard]

Hi Simon K.,

We had that discussion not long ago on another post. We're actually retyping
the whole thing, but mimicking the official JavaDoc. Since it's not copied
directly it seems it's allowed.

~ Simon

On Tue, Dec 9, 2008 at 10:06 AM, Simon Kitching <[EMAIL PROTECTED]>wrote:

> Hmm..by the way, are you copying-and-pasting the JSF javadoc into
> myfaces classes? If so, are you sure that this is allowed? Javadoc
> descriptions would definitely be copyrightable, so explicit permission
> would be needed to place text released under the CDDL into a file
> licensed under the Apache license...
>
> In Myfaces core 1.1 and 1.2 releases we have been careful to NOT copy
> any javadoc from the spec..
>
> Regards,
> Simon
>
> >> Simon Lessard wrote:
> >>
> >>> To be more precise checkstyle whines about missing @param and @return,
> >>> which
> >>> is theoretically nice. However, JSF's JavaDoc is broken and doesn't
> >>> specifies those most of the time, so the question is is it better to
> match
> >>> the official API or to make checkstyle happy?
> >>>
> >>> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
> >>> <[EMAIL PROTECTED]>wrote:
> >>>
> >>>
>  Hi all,
> 
>  It seems that checkstyle doesn't like JSF's official JavaDoc.
> Personally
>  I
>  would give higher priority to completed comments than checkstyle
> whining,
>  what you guys think about it?
> 
> 
>
>

Requirements for skinning module

[Simon Lessard]

Hi,

This post is to determine the requirements of a common skinning module for
MyFaces and potentially for JSF 2.0 if good enough. It's following the post
about skinning from the previous days. I'll leave this post opened for 72
hours then we'll start designing accordingly, most likely starting from what
I proposed in the aforementioned skinning post with some potential changes
to fit the requirements we're going to choose.

Paul Rivera proposed the following list:

from trinidad:

   - basic css style skinning
   - global styles/aliases
   - skin extensions
   - skin additions for custom component developers
   - properties skinning
   - icon skinning
   - text skinning / translations
  - using bundle-name
  - using translation-source
   - skin variants based on:
  - agent name
  - agent version
  - platform name
  - accessibility-profile
  - direction (:rtl)
  - locale (@locale, :lang) -> Accdg to the skinning guide, this is not
  yet implemented in trinidad
   - dynamically changing skins at runtime
   - compressed styleclass names feature
   - CHECK_FILE_MODIFICATION feature
   - And as Jeanne mentioned, compatibility with portals.  I don't have much
   experience with portals.  I will probably need to look more into this.

added requirements:

   - tomahawk-support: make use of AddResource and ExtensionsFilter
   - generic-support


Personally I disagree quite a lot with that list. Not that those aren't nice
features, it's just that they're implementation details and not API
requirements imho. I would indeed like to see a special implementation
support all that, I would just not link them o the base API in any way.
Among other thing it expose way too much about the rendering technology
being used and nothing about the extensibility requirement that fits JSF
architecture. My own list would look like the following. It's a priority
list so I believe overdoing a lower requirement at the expense of the higher
shouldn't be done:

The skinning module should

   1. Be pluggable like other JSF modules (various handlers)
   2. Allow skin composition and extension for maximum reuse and enforce
   better interoperability between various extensions
   3. Allow skin change at runtime
   4. Be localizable
   5. Leverages existing API (JSF 2.0) whenever possible rather than adding
   extra classes and methods
   6. Be independant from the rendering technology used (not necessarily CSS
   for HTML render kit)
   7. Allow maximum compatibility with existing skin/theme modules
   (Trinidad, IceFaces, Richfaces), not necessarily by providing direct support
   for those feature but by allowing extension to implement those features
   using the module's API
   8. Be fast, the module shouldn't induce an inherent performance overhaul


My list is way more general, but you can place some of what Paul mentioned
in one of them so here's Paul list again but with what requirement it would
fall in in my list. The elements in green are covered by the requirements,
those in red are implementation detail that shouldn't be required for all
implementation and the skin's general contract. Elements in blue are those
that should have a requirement but currently don't because I don't know how
to put them down or if they really should be requirement and finally,
elements in orange are relevant but that I didn't consider in my proposed
API (which is a problem):

from trinidad:

   - basic css style skinning (implementation detail, not a hard
   requirement)
   - global styles/aliases (implementation detail, not a hard requirement)
   - skin extensions (REQ 2 through extension)
   - skin additions for custom component developers (REQ 2 through
   composition)
   - properties skinning (Not currently a requirement)
   - icon skinning (Not currently a requirement)
   - text skinning / translations (REQ 4)
   - using bundle-name
  - using translation-source
   - skin variants based on: (implementation detail, not a hard requirement,
   could be implemented at RenderKit level, Factory level or loader level with
   what I proposed)
  - agent name
  - agent version
  - platform name
  - accessibility-profile
  - direction (:rtl)
  - locale (@locale, :lang) -> Accdg to the skinning guide, this is not
  yet implemented in trinidad
   - dynamically changing skins at runtime (REQ 3)
   - compressed styleclass names feature (implementation detail, not a hard
   requirement)
   - CHECK_FILE_MODIFICATION feature (implementation detail, not a hard
   requirement)
   - And as Jeanne mentioned, compatibility with portals.  I don't have much
   experience with portals.  I will probably need to look more into
this.(REQ 1, through module override the portlet bridge could most
likely achieve
   it, adding explicit support for that would go against REQs 1, 5, 6 and 7 I
   think)

added requirements:

   - tomahawk-support: make use of AddResource and
ExtensionsFilter(implementation detail, not a 

[jira] Created: (TRINIDAD-1339) tr:validateRegExp does not accept regex strings

[George Kraev (JIRA)]

tr:validateRegExp does not accept regex strings
---

 Key: TRINIDAD-1339
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1339
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.10-core
 Environment: Windows XP/Vista, Apache Tomcat 6.0.18
Reporter: George Kraev


Code that used to work in version 1.0.7 of Trinidad no longer works in 1.0.10. 
All regular expressions that we have tried fail to evaluate and you get a 
validation problem. Moreover, the Trinidad examples for 1.0.10 also do not work 
with regex. Does anyone have a clue as to why I'm having problems? Can someone 
check if the regex examples from the demo code for trinidad is working 
correctly? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: JavaDoc and checkstyle

[Gerhard Petracek]

hello simon,

i already brought up this topic at [1]
did it happen again?

if so:
maybe it's helpful to write a general e-mail to the dev list and/or a wiki
about this topic.

regards,
gerhard

[1]
http://www.nabble.com/Re%3A--JSF-2.0--Package-structure-for-Facelets-integration-p20798004.html



2008/12/9 Simon Kitching <[EMAIL PROTECTED]>

> Hmm..by the way, are you copying-and-pasting the JSF javadoc into
> myfaces classes? If so, are you sure that this is allowed? Javadoc
> descriptions would definitely be copyrightable, so explicit permission
> would be needed to place text released under the CDDL into a file
> licensed under the Apache license...
>
> In Myfaces core 1.1 and 1.2 releases we have been careful to NOT copy
> any javadoc from the spec..
>
> Regards,
> Simon
>
> >> Simon Lessard wrote:
> >>
> >>> To be more precise checkstyle whines about missing @param and @return,
> >>> which
> >>> is theoretically nice. However, JSF's JavaDoc is broken and doesn't
> >>> specifies those most of the time, so the question is is it better to
> match
> >>> the official API or to make checkstyle happy?
> >>>
> >>> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
> >>> <[EMAIL PROTECTED]>wrote:
> >>>
> >>>
>  Hi all,
> 
>  It seems that checkstyle doesn't like JSF's official JavaDoc.
> Personally
>  I
>  would give higher priority to completed comments than checkstyle
> whining,
>  what you guys think about it?
> 
> 
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: JavaDoc and checkstyle

[Bruno Aranda]

That and rewriting any XML schema by hand. That was a funny one.

Bruno

2008/12/9 Simon Kitching <[EMAIL PROTECTED]>

> Hmm..by the way, are you copying-and-pasting the JSF javadoc into
> myfaces classes? If so, are you sure that this is allowed? Javadoc
> descriptions would definitely be copyrightable, so explicit permission
> would be needed to place text released under the CDDL into a file
> licensed under the Apache license...
>
> In Myfaces core 1.1 and 1.2 releases we have been careful to NOT copy
> any javadoc from the spec..
>
> Regards,
> Simon
>
> >> Simon Lessard wrote:
> >>
> >>> To be more precise checkstyle whines about missing @param and @return,
> >>> which
> >>> is theoretically nice. However, JSF's JavaDoc is broken and doesn't
> >>> specifies those most of the time, so the question is is it better to
> match
> >>> the official API or to make checkstyle happy?
> >>>
> >>> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
> >>> <[EMAIL PROTECTED]>wrote:
> >>>
> >>>
>  Hi all,
> 
>  It seems that checkstyle doesn't like JSF's official JavaDoc.
> Personally
>  I
>  would give higher priority to completed comments than checkstyle
> whining,
>  what you guys think about it?
> 
> 
>
>

Re: JavaDoc and checkstyle

[Simon Kitching]

Hmm..by the way, are you copying-and-pasting the JSF javadoc into
myfaces classes? If so, are you sure that this is allowed? Javadoc
descriptions would definitely be copyrightable, so explicit permission
would be needed to place text released under the CDDL into a file
licensed under the Apache license...

In Myfaces core 1.1 and 1.2 releases we have been careful to NOT copy
any javadoc from the spec..

Regards,
Simon

>> Simon Lessard wrote:
>> 
>>> To be more precise checkstyle whines about missing @param and @return,
>>> which
>>> is theoretically nice. However, JSF's JavaDoc is broken and doesn't
>>> specifies those most of the time, so the question is is it better to match
>>> the official API or to make checkstyle happy?
>>>
>>> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
>>> <[EMAIL PROTECTED]>wrote:
>>>
>>>   
 Hi all,

 It seems that checkstyle doesn't like JSF's official JavaDoc. Personally
 I
 would give higher priority to completed comments than checkstyle whining,
 what you guys think about it?

 

Re: [Skinning] Independent skinning myfaces subproject

[Matthias Wessendorf]

On Tue, Dec 9, 2008 at 2:23 PM, Gerhard Petracek
<[EMAIL PROTECTED]> wrote:
> hello,
>
> concerning the accessibility mode: is trinidad tested with real
> screen-readers?

we use jaws

> furthermore, we should specify if we are talking about skinning or theming.
>
> regards,
> gerhard
>
>
>
> 2008/12/9 Paul Rivera <[EMAIL PROTECTED]>
>>
>> Hi,
>>
>> I agree with Jeanne as well regarding the requirements.  This has been the
>> list of requirements we've used as a guide in building the skinning
>> project.  Maybe we can use this as a starting point.  Feel free to modify
>> the list.
>>
>> from trinidad:
>> * basic css style skinning
>> * global styles/aliases
>> * skin extensions
>> * skin additions for custom component developers
>> * properties skinning
>> * icon skinning
>> * text skinning / translations
>>   - using bundle-name
>>   - using translation-source
>> * skin variants based on:
>>   - agent name
>>   - agent version
>>   - platform name
>>   - accessibility-profile
>>   - direction (:rtl)
>>   - locale (@locale, :lang) -> Accdg to the skinning guide, this is not
>> yet implemented in trinidad
>> * dynamically changing skins at runtime
>> * compressed styleclass names feature
>> * CHECK_FILE_MODIFICATION feature
>> * And as Jeanne mentioned, compatibility with portals.  I don't have much
>> experience with portals.  I will probably need to look more into this.
>>
>> added requirements:
>> * tomahawk-support: make use of AddResource and ExtensionsFilter
>> * generic-support
>>
>> As for simon's issue on style class / property / icon access strategy
>> (sub-issue 3.1), I've read somewhere that hashcode is already cached in
>> String since java 1.3.  I've not really verified this on java 1.3.  But I
>> did check on jdk 1.6 and confirmed that it does cache hashcode.  Here's the
>> snippet fro java.lang.String:
>>
>> public int hashCode() {
>> int h = hash;
>> if (h == 0) {
>> int off = offset;
>> char val[] = value;
>> int len = count;
>>
>> for (int i = 0; i < len; i++) {
>> h = 31*h + val[off++];
>> }
>> hash = h;
>> }
>> return h;
>> }
>>
>> Best Regards,
>> Paul Rivera
>>
>> --- On Tue, 12/9/08, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
>>
>> From: Matthias Wessendorf <[EMAIL PROTECTED]>
>> Subject: Re: [Skinning] Independent skinning myfaces subproject
>> To: "MyFaces Development" 
>> Date: Tuesday, December 9, 2008, 12:52 AM
>>
>> On Tue, Dec 9, 2008 at 1:03 AM, Jeanne Waldman
>> <[EMAIL PROTECTED]> wrote:
>> >
>>  What about Step A - requirements? We should list out the requirements we
>> > have so we can make sure we aren't missing anything. There's been
>> a lot of
>> > work in getting the skinning to work with portals, so we'll need that
>>
>> to
>> > still work and we will probably want to redesign it since it's kind of
>> lame
>> > the way it works right now.
>>
>> +1
>> good point, Jeanne, we don't want to see that work destroyed.
>>
>> -M
>>
>>
>> >
>> > From my experience coming up with a good API takes a lot of time. I'll
>> try
>> > to find some time to read your proposal at least.
>> >
>> > Jeanne
>> >
>> > Simon Lessard wrote, On 12/8/2008 6:16 AM PT:
>>
>> >>
>> >> I would prefer a roadmap like:
>> >>
>> >>   1. Design a modular API that fits Trinidad's needs with minimal
>> >>  compatibility loss.
>> >>   2. In parallel
>> >> 1. Start implementing the API defined in 1.
>>  as a myfaces
>> >>extension, possibily along with a ResourceHandler for JSF
>> 1.2
>> >>   2. Propose the API to JSF 2.0 EG
>> >>   3. If the API make it the the spec then
>> >> 1. Convert the extension to fit the new API (even if target
>>
>> >>is 1.2 it should be possible but in a different package)
>> >> 2. Integrate the API with the corect package naming to the
>> >>2.0 branch (obviously)
>> >>   4. In the API doesn't get in the spec, then create a 2.0 branch
>>
>> of
>> >>  the skin extension
>> >>   5. Convert Trinidad to the new extension
>> >>   6. Integrate the extension in Tomahawk and Tobago
>> >>
>> >>
>> >> So, for now, I would really really like to get comments from the
>>
>> community
>> >> on the API I proposed as well as potential solutions for the pendings.
>> >> Otherwise I'll have to
>>  propose it in its current form and that
>> would prevent
>> >> the API to be reviewed by the MyFaces community and that would be a
>> shame
>> >> imho. As I mentioned before, time is running really short and the fact
>>
>> that
>> >> 2.0 is in public review phase alone might prevent the addition of such
>> core
>> >> API in the spec so the faster we can design a great API, the more
>> chances
>> >> there is to see it standardized.
>>
>> >>
>> >>
>> >> Regards,
>> >>
>> >> ~ Simon
>> >>
>> >> On Mon, Dec 8, 2008 at 4:22 AM, Gerhard Petracek
>> >> <[EMAIL PROTECTED]
>>
>> > wrote:
>> >>
>> >>hello 

Re: JavaDoc and checkstyle

[Bernd Bohmann]

+1

Simon Kitching schrieb:
> I would also prefer to change the checkstyle rules to ignore missing @param
> and @return comments. 
> 
> Sometimes params really are obvious enough not to be documented, and in some
> other cases it is better to document them as part of the main method
> description rather than a separate tag. So blindly enforcing this check
> doesn't seem helpful...
> 
> 
> Simon Lessard wrote:
>> To be more precise checkstyle whines about missing @param and @return,
>> which
>> is theoretically nice. However, JSF's JavaDoc is broken and doesn't
>> specifies those most of the time, so the question is is it better to match
>> the official API or to make checkstyle happy?
>>
>> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
>> <[EMAIL PROTECTED]>wrote:
>>
>>> Hi all,
>>>
>>> It seems that checkstyle doesn't like JSF's official JavaDoc. Personally
>>> I
>>> would give higher priority to completed comments than checkstyle whining,
>>> what you guys think about it?
>>>
> 

Re: JavaDoc and checkstyle

[Jan-Kees van Andel]

I wouldn't change the CheckStyle rules to ignore missing @params. Why?
Because often you (well, probably not you, but someone else) changes a
param name but forgets to change the corresponding JavaDoc. CheckStyle
is a good way to warn you about this.

@returns are most of the time redundant since the method description
usually already says something about what's returned. But even then,
it might be useful to use a @return for exceptional paths, like "this
method returns null if yadayada".

You could change the checkstyle to only report a warning in such
cases, instead of an error. This way, you get the desired warning
effect, but the error is less annoying.

Jan-Kees


2008/12/9 Simon Kitching <[EMAIL PROTECTED]>:
>
> I would also prefer to change the checkstyle rules to ignore missing @param
> and @return comments.
>
> Sometimes params really are obvious enough not to be documented, and in some
> other cases it is better to document them as part of the main method
> description rather than a separate tag. So blindly enforcing this check
> doesn't seem helpful...
>
>
> Simon Lessard wrote:
>>
>> To be more precise checkstyle whines about missing @param and @return,
>> which
>> is theoretically nice. However, JSF's JavaDoc is broken and doesn't
>> specifies those most of the time, so the question is is it better to match
>> the official API or to make checkstyle happy?
>>
>> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
>> <[EMAIL PROTECTED]>wrote:
>>
>>> Hi all,
>>>
>>> It seems that checkstyle doesn't like JSF's official JavaDoc. Personally
>>> I
>>> would give higher priority to completed comments than checkstyle whining,
>>> what you guys think about it?
>>>
>>
>
> --
> View this message in context: 
> http://www.nabble.com/JavaDoc-and-checkstyle-tp20803530p20911066.html
> Sent from the My Faces - Dev mailing list archive at Nabble.com.
>
>

Re: myfaces commons modules

[Leonardo Uribe]

On Tue, Dec 9, 2008 at 4:55 AM, Simon Kitching <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Firstly: I've noticed that the maven repo contains a lot of garbage
> files. For example, in here:
>
>
> http://repo2.maven.org/maven2/org/apache/myfaces/commons/myfaces-commons-utils12/1.0.0/
> there are lots of ".asc.asc" files. These are created automatically by
> our maven build commands and should NOT be copied to the maven repo
> directory. I suggest contacting the [EMAIL PROTECTED] list to get
> these removed; they don't do any actual harm but are pointless garbage.
>
> Secondly: I was looking for the commons-components12 module, but don't
> see it in the list. Is it missing, or was the "components" submodule it
> not part of the 1.0 release?
>
Hi

commons-components12 was not part of 1.0 release

regards

Leonardo Uribe


>
> Thanks,
> Simon
>
>

myfaces commons modules

[Simon Kitching]

Hi,

Firstly: I've noticed that the maven repo contains a lot of garbage
files. For example, in here:
   
http://repo2.maven.org/maven2/org/apache/myfaces/commons/myfaces-commons-utils12/1.0.0/
there are lots of ".asc.asc" files. These are created automatically by
our maven build commands and should NOT be copied to the maven repo
directory. I suggest contacting the [EMAIL PROTECTED] list to get
these removed; they don't do any actual harm but are pointless garbage.

Secondly: I was looking for the commons-components12 module, but don't
see it in the list. Is it missing, or was the "components" submodule it
not part of the 1.0 release?

Thanks,
Simon

[jira] Commented: (ORCHESTRA-22) portlet: Error creating bean with name 'org.apache.myfaces.orchestra.conversation.AccessScopeManager'

[Simon Kitching (JIRA)]

[ 
https://issues.apache.org/jira/browse/ORCHESTRA-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654743#action_12654743
 ] 

Simon Kitching commented on ORCHESTRA-22:
-

The current Orchestra developers (Mario and myself) do not use portlets. So 
getting Orchestra working in portlet environments is waiting for someone who 
actually uses portlets to step up and do it. There have been no volunteers so 
far..

> portlet: Error creating bean with name 
> 'org.apache.myfaces.orchestra.conversation.AccessScopeManager'
> -
>
> Key: ORCHESTRA-22
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-22
> Project: MyFaces Orchestra
>  Issue Type: Bug
>  Components: Conversation
>Affects Versions: 1.1
> Environment: myfaces 1.1.5, myfaces-orchestra-core1.1, 
> ascpectel-1.0-Snapshot,liferay portal 4.3.3
>Reporter: Rashmi
>
> Hello,
> When I deploy the portal application in Liferay 4.3.3, I am getting the 
> following exception: 
> 2008-04-11 12:59:02,875 ERROR 
> [org.apache.myfaces.lifecycle.PhaseListenerManager] - Exception in 
> PhaseListener RENDER_RESPONSE(6) beforePhase.
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.myfaces.orchestra.conversation.AccessScopeManager': 
> Scope 'request' is not active for the current thread; consider defining a 
> scoped proxy for this bean if you intend to refer to it from a singleton; 
> nested exception is java.lang.IllegalStateException: No thread-bound request 
> found: Are you referring to request attributes outside of an actual web 
> request? If you are actually operating within a web request and still receive 
> this message,your code is probably running outside of 
> DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener 
> or RequestContextFilter to expose the current request.
> Caused by: 
> java.lang.IllegalStateException: No thread-bound request found: Are you 
> referring to request attributes outside of an actual web request? If you are 
> actually operating within a web request and still receive this message,your 
> code is probably running outside of DispatcherServlet/DispatcherPortlet: In 
> this case, use RequestContextListener or RequestContextFilter to expose the 
> current request.
>   at 
> org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:102)
>   at 
> org.springframework.web.context.request.AbstractRequestAttributesScope.get(AbstractRequestAttributesScope.java:40)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160)
>   at 
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:733)
>   at 
> org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(DelegatingVariableResolver.java:122)
>   at 
> org.apache.myfaces.orchestra.frameworkAdapter.jsf.JsfFrameworkAdapter.getBean(JsfFrameworkAdapter.java:174)
>   at 
> org.apache.myfaces.orchestra.conversation.AccessScopeManager.getInstance(AccessScopeManager.java:88)
>   at 
> org.apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener.beforePhase(AccessScopePhaseListener.java:91)
>   at 
> org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:73)
>   at 
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:126)
>   at 
> org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:397)
>   at 
> org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:377)
>   at 
> de.seat.common.portlet.jsf.MyFacesFaceletPortlet.facesRender(MyFacesFaceletPortlet.java:156)
>   at 
> org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:323)
>   at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:235)
>   at javax.portlet.GenericPortlet.render(GenericPortlet.java:163)
>   at 
> de.seat.common.portlet.jsf.MyFacesFaceletPortlet.render(MyFacesFaceletPortlet.java:117)
>   at 
> com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:107)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)

Re: JavaDoc and checkstyle

[Simon Kitching]

I would also prefer to change the checkstyle rules to ignore missing @param
and @return comments. 

Sometimes params really are obvious enough not to be documented, and in some
other cases it is better to document them as part of the main method
description rather than a separate tag. So blindly enforcing this check
doesn't seem helpful...


Simon Lessard wrote:
> 
> To be more precise checkstyle whines about missing @param and @return,
> which
> is theoretically nice. However, JSF's JavaDoc is broken and doesn't
> specifies those most of the time, so the question is is it better to match
> the official API or to make checkstyle happy?
> 
> On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard
> <[EMAIL PROTECTED]>wrote:
> 
>> Hi all,
>>
>> It seems that checkstyle doesn't like JSF's official JavaDoc. Personally
>> I
>> would give higher priority to completed comments than checkstyle whining,
>> what you guys think about it?
>>
> 

-- 
View this message in context: 
http://www.nabble.com/JavaDoc-and-checkstyle-tp20803530p20911066.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.

[jira] Updated: (MFCOMMONS-2) ExporterActionListener should be dependant of UIData instead of HtmlDataTable

[Gilles Demarty (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MFCOMMONS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles Demarty updated MFCOMMONS-2:
---

Status: Patch Available  (was: Open)

> ExporterActionListener should be dependant of UIData instead of HtmlDataTable
> -
>
> Key: MFCOMMONS-2
> URL: https://issues.apache.org/jira/browse/MFCOMMONS-2
> Project: MyFaces Commons
>  Issue Type: Bug
>  Components: myfaces-commons-components
>Affects Versions: 1.0.1-SNAPSHOT
> Environment: myfaces 1.2.4 + richfaces 3.2.2.SR1 + jetty
>Reporter: Gilles Demarty
> Attachments: switch-HtmlDataTable-To-UIData-patch.txt
>
>
> Right now, the component  cast the for attribute 
> as a htmlDataTable. It does not allow other implementations of UIData to be 
> used with this component (e.g. richfaces one). Is there any reasons to do 
> that ? 
> Changing all the htmlDataTable to UIData in those classes provides a 
> satisfying solution without any visible drawbacks.
> By the way, in ExporterActionListenr, the cast cast test that throws the 
> correct message is thrown after the cast, thus the message return in the web 
> page is a ClassCastException, not a RuntimeException

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Skinning] Independent skinning myfaces subproject

[Matthias Wessendorf]

On Tue, Dec 9, 2008 at 1:03 AM, Jeanne Waldman
<[EMAIL PROTECTED]> wrote:
> What about Step A - requirements? We should list out the requirements we
> have so we can make sure we aren't missing anything. There's been a lot of
> work in getting the skinning to work with portals, so we'll need that to
> still work and we will probably want to redesign it since it's kind of lame
> the way it works right now.

+1
good point, Jeanne, we don't want to see that work destroyed.

-M

>
> From my experience coming up with a good API takes a lot of time. I'll try
> to find some time to read your proposal at least.
>
> Jeanne
>
> Simon Lessard wrote, On 12/8/2008 6:16 AM PT:
>>
>> I would prefer a roadmap like:
>>
>>   1. Design a modular API that fits Trinidad's needs with minimal
>>  compatibility loss.
>>   2. In parallel
>> 1. Start implementing the API defined in 1. as a myfaces
>>extension, possibily along with a ResourceHandler for JSF 1.2
>>   2. Propose the API to JSF 2.0 EG
>>   3. If the API make it the the spec then
>> 1. Convert the extension to fit the new API (even if target
>>is 1.2 it should be possible but in a different package)
>> 2. Integrate the API with the corect package naming to the
>>2.0 branch (obviously)
>>   4. In the API doesn't get in the spec, then create a 2.0 branch of
>>  the skin extension
>>   5. Convert Trinidad to the new extension
>>   6. Integrate the extension in Tomahawk and Tobago
>>
>>
>> So, for now, I would really really like to get comments from the community
>> on the API I proposed as well as potential solutions for the pendings.
>> Otherwise I'll have to propose it in its current form and that would prevent
>> the API to be reviewed by the MyFaces community and that would be a shame
>> imho. As I mentioned before, time is running really short and the fact that
>> 2.0 is in public review phase alone might prevent the addition of such core
>> API in the spec so the faster we can design a great API, the more chances
>> there is to see it standardized.
>>
>>
>> Regards,
>>
>> ~ Simon
>>
>> On Mon, Dec 8, 2008 at 4:22 AM, Gerhard Petracek
>> <[EMAIL PROTECTED] > wrote:
>>
>>hello paul,
>>
>>ok - let's continue with the case you mentioned.
>>
>>we could:
>> - use the same approach of the myfaces shared module also for the
>>shared skinning code
>> - provide skinning as an independent jar file (it's easier for
>>other projects/custom components to re-use it)
>>
>>regards,
>>gerhard
>>
>>
>>
>>2008/12/8 Paul Rivera <[EMAIL PROTECTED]
>>>
>>
>>Hi,
>>
>>It's good to hear that there's effort done to make skinning
>>standardized and part of JSF by Simon.  Is there anything that
>>the current skinning project we have at
>>http://code.google.com/p/myfaces-csi/ can contribute to this?
>>
>>In the event that Simon's ideas don't get integrated into JSF
>>2.0, I'd like to bring back the discussion to the skinning
>>project that we now have in the link mentioned above.
>>
>>Overall, I think the community agrees with the idea of having
>>an independent skinning project that is basically derived from
>>trinidad code.  I'd like to hear your opinion on the project
>>layout described in
>>http://code.google.com/p/myfaces-csi/wiki/MyfacesSkinsProposal.
>>
>>What concerns me most here is that the skins project and
>>trinidad share a lot of classes that it is hard to get a clean
>>separation.  You can check shared-impl for those classes.
>>
>>Our current layout has a shared module (shared-api,
>>shared-impl).  This module contains code shared by both
>>skinning and trinidad-core.  We can probably move some of the
>>utility classes into myfaces-commons-utils.  But other classes
>>there might not be such a good fit into myfaces-commons-utils.
>>
>>We started this project with the most immediate goal of giving
>>tomahawk skinning support and eventually have trinidad use
>>this project.  We've taken trinidad skinning code and now it
>>works with tomahawk and trinidad-core.  In the event that this
>>project gets accepted into myfaces, integration with tomahawk
>>is not a big problem.  I am actually more worried with the
>>changes we have to make in trinidad-core.  This is why I'd
>>like to propose as a roadmap:
>>  - finish the skinning project and make the necessary changes
>>in trinidad-core without adding new features yet to the
>>current set that trinidad has.  There will be big changes in
>>trinidad-core that need to be done at the same time.
>>  - once we verify that everything is working, we can then add
>>the desired new features/changes to the skinni

Re: JSF 1.2.x nighty builds ?

[Matthias Wessendorf]

eh...

wrong list :-)

On Tue, Dec 9, 2008 at 9:48 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> I was looking at:
> https://javaserverfaces.dev.java.net/servlets/ProjectDocumentList?folderID=1703&expandFolder=1703&folderID=1503
>
> and I didn't see an up to date nightly. Any idea, where these artifacts are ?
>
> -Matthias
>
> --
> 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

JSF 1.2.x nighty builds ?

[Matthias Wessendorf]

Hi guys,

I was looking at:
https://javaserverfaces.dev.java.net/servlets/ProjectDocumentList?folderID=1703&expandFolder=1703&folderID=1503

and I didn't see an up to date nightly. Any idea, where these artifacts are ?

-Matthias

-- 
Matthias Wessendorf

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