[jira] Resolved: (TRINIDAD-556) Allow skins to inherit something else than simple skin

[Simon Lessard (JIRA)]

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

Simon Lessard resolved TRINIDAD-556.


Fix Version/s: 1.2.1-core
   1.0.1-core
   Resolution: Fixed

Indeed it is.

> Allow skins to inherit something else than simple skin
> --
>
> Key: TRINIDAD-556
> URL: https://issues.apache.org/jira/browse/TRINIDAD-556
> Project: MyFaces Trinidad
>  Issue Type: Improvement
>Affects Versions: 1.0.1-incubating-core-SNAPSHOT
>    Reporter: Simon Lessard
> Fix For: 1.2.1-core, 1.0.1-core
>
>
> Create a document level -import or -extends skin command that would allow the 
> current CSS to inherit from the specified skin rather than simple one. The 
> main difficulty that I see with this will be the localisation algorithm to 
> use.
> It could be -extends(skinFamily) or -extends(skinId) then find the right 
> parent CSS using adf-faces-skins.xml. If family is used instead of id, the 
> current CSS' entry would have to be found to generate the right id (desktop 
> or pda for example). Circular references would also need to be checked to 
> prevent infinite recursion of course.

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

Re: proposed API change on ChangeManager

[Simon Lessard]

+0, see below for the why.

Blake,

Let see if I understand the issue correctly. We have:

- Detect a row key change (can happen if the rowKey is the PK and the PK
changes during the request processing). See 1) & 2) below please
  - Now, if the selectedRowKeys attribute, or any other attribute with a
rowKey value, was persisted within the ChangeManager, you need to update
that reference as well;
  - However, if the attribute was NOT persisted, then you don't need to do
anything;
  - So, the issue is that we have no way to know if the attribute was
persisted or not, hence why you want the new method, replacing the change if
it was previously added.

If this is correct, then what will we do when the same issue show up, but
someone has created a special AddChildComponentChange creating a component
instance with a non null selectedRowKeys attribute? We could tell him to
split his change in two I guess, or we could have a replaceComponentChange
method.

Although I love the ChangeManager feature, I'm starting to feel like we have
opened a Pandora box. If it was still possible, I would have redesigned it
from scratch with a finite set of possible changes and a method for each of
them so that reverse operation could be detected more easily. However, both
MDS and ADF Faces Rich Client and its persisted attribute are too advanced
and big for that, not to mention unknown implementations by various users.
For our project, an empty method in the abstract class won't hurt, let hope
the same holds true for others. I still don't like that request at all, but
since I have nothing better to suggest other than prohibiting persistence of
any rowKey based attributes, I'll turn my vote to a +0.

1) I assume your issue show up with FacesCtrlHierNodeBinding when using an
Entity object with a primary key attribute set to refresh after insert and
populated by a trigger from a sequence? If so, there are other cleaner way
around this using a better CollectionModel implementation, we have that on
our project too, but that might not fix the problem if the temporary rowKey
has been persisted within the ChangeManager however.

2) How do you detect that change since you need to if you are to notify the
ChangeManager?


Regards,

~ Simon

On Fri, Apr 9, 2010 at 7:17 PM, Blake Sullivan wrote:

>  Simon,
>
> The use case is this:
>
> Say I have a table with a selectedRowKeys attribute that contains the
> identifiers for the currently selected rows.  If my application allows a row
> key to change (perhaps during creation or because the application actually
> allows the fields that make up the primary key to be edited), we have a
> problem because we have a stale key reference.  We would like to update that
> reference with the new key, but the table doesn't know if some other piece
> of code has added the table's selectedRowKeys attribute.  So the table wants
> to check if the selectedRowKeys are already in the ChangeManager and if they
> are, add a new change.  You are right that whether the change actually
> replaces the old change or not is irrelevant as long as the result is that
> the new achange eclipses the old.  So, we have one function that does
> everything, but we could also add a new function to see if the ChangeManager
> contains an attribute change instead.
>
> -- Blake Sullivan
>
> Simon Lessard said the following On 4/8/2010 6:17 AM PT:
>
> -1. I really don't like it. It should be an implementation detail of the
> ChangeManager to either replace/chain the attribute change in the
> addComponentChange (or any other change for that matter). We have an
> implementation on our project doing just that. That method would make no
> sense for our use case and would introduce backward compatibility issues. I
> could change my opinion, but I'd like a detailed use case as of why this
> cannot be just an implementation detail before I do.
>
>
> Regards,
>
> ~ Simon
>
> On Wed, Apr 7, 2010 at 5:17 PM, Yuan Gao  
>  wrote:
>
>
>
>  hi,
>
> For JIRA 1761 (https://issues.apache.org/jira/browse/TRINIDAD-1761), we
> propose to add this API to the ChangeManager interface:
>  /**
>   * Replace an AttributeComponentChange if it's present.
>   *
>   * @param facesContext
>   * @param uiComponent
>   * @param attributeComponentChange
>   * @return the old change instance
>   */
>  public AttributeComponentChange
> replaceAttributeChangeIfPresent(FacesContext facesContext,
>UIComponent uiComponent,
>AttributeComponentChange attributeComponentChange);
>
>
> Let me know what do you think about it.
>
> Thanks,
> -Yuan
>
>
>
>
>
>
>

Re: proposed API change on ChangeManager

[Simon Lessard]

-1. I really don't like it. It should be an implementation detail of the
ChangeManager to either replace/chain the attribute change in the
addComponentChange (or any other change for that matter). We have an
implementation on our project doing just that. That method would make no
sense for our use case and would introduce backward compatibility issues. I
could change my opinion, but I'd like a detailed use case as of why this
cannot be just an implementation detail before I do.


Regards,

~ Simon

On Wed, Apr 7, 2010 at 5:17 PM, Yuan Gao  wrote:

> hi,
>
> For JIRA 1761 (https://issues.apache.org/jira/browse/TRINIDAD-1761), we
> propose to add this API to the ChangeManager interface:
>  /**
>   * Replace an AttributeComponentChange if it's present.
>   *
>   * @param facesContext
>   * @param uiComponent
>   * @param attributeComponentChange
>   * @return the old change instance
>   */
>  public AttributeComponentChange
> replaceAttributeChangeIfPresent(FacesContext facesContext,
>UIComponent uiComponent,
>AttributeComponentChange attributeComponentChange);
>
>
> Let me know what do you think about it.
>
> Thanks,
> -Yuan
>
>
>

Re: [MyFaces 2] Impact of view scope

[Simon Lessard]

Hi,

You could also override the readResolve method of your application scoped
bean to reflect its singleton status. However that does create an annoying
dependency since the application scoped bean will knows its managed bean
name. But if you're using @ManagedBean or @Named, it already does anyway.


Regards,

~ Simon

On Sun, Jan 17, 2010 at 3:18 PM, Michael Kurz  wrote:

> Jakob Korherr schrieb:
>
>  Hi Michael,
>>
>> I guess that is the expected behavior...
>>
>> Also: isn't this serialize and deserialize behavior the same if you use a
>> session bean with a reference to an application bean? At least at the time
>> when the session is serialized (e.g. cluster with session replication)..
>>
>
> Sure, it is (and was) the same in this case but for the view scope it will
> affect more applications I guess.
>
> -
> Michael
>

Re: [Trinidad] New Component Showcase Demo and Casablanca Skin

[Simon Lessard]

Looks great, thanks!

On Thu, Jan 7, 2010 at 7:17 PM, Bruno Aranda  wrote:

> Excellent! Looks fantastic. Something long due to trinidad.
>
> Thanks,
>
> Bruno
>
> 2010/1/7 Matt Cooper 
>
> Wow this looks fantastic, nice work!
>>
>> Thanks,
>> Matt
>>
>>
>> On Thu, Jan 7, 2010 at 3:37 PM, Catalin Kormos 
>> wrote:
>>
>>> Hello there,
>>>
>>> I have the pleasure to inform you about the work we did to develop a new
>>> skin for Trinidad and based on this a brand new, Trinidad components
>>> showcase application. You can see it all in action at [1]. It is still a
>>> working in progress, in advanced state though...i mean there is always
>>> something to be improved; nevertheless we would like to donate the new skin
>>> and the new demo application to the MyFaces community, in its current state,
>>> and continue there if you guys agree.
>>>
>>> Many thanks go to my collegue Adonis who has put a lot of effort into
>>> designing and implementing the new skin called 'Casablanca'. I'm sure he can
>>> give you more details as needed about how the process went.
>>>
>>> A few words about the new demo:
>>>
>>>-  first of all, many thanks to another collegue of mine, Cosmin, for
>>>his continuos efforts with this.
>>>- the demo is working only with facelets (there is no jsp version)
>>>- it uses the latest 1.2.13-SNAPSHOT version of Trinidad
>>>- we tryied to build it so it can be searched online also, currently
>>>tryied with Google Custom Search, but this didn't work out so smoothly so
>>>far. In any case, that's the reason for the pretty urls used. (so, no 
>>> point
>>>in trying the search currently as it doesn't work).
>>>- in general, it replicates the examples available already for
>>>Trinidad in the existing demo, in someplaces slightly improved.
>>>- it tryies to provide a platform on which to build much more demos
>>>as required as there can be always new ideas about demoing a meaningfull 
>>> use
>>>case on Trinidad, or some component behaviour.
>>>
>>> I'm eager to get your reactions, I think these guys did a great job so
>>> far and this would bring Trinidad at least a few steps closer to a more
>>> appealing and user friendly component set.
>>>
>>>  regards,
>>> Catalin
>>>
>>> [1] http://example.irian.at/trinidad-showcase-casablanca
>>>
>>> 
>>> Codebeat
>>> www.codebeat.ro
>>>
>>
>>
>

Re: [TRINIDAD][API]TRINIDAD-1668 Speed up UIXComponent.getId()

[Simon Lessard]

That works as well, not optimal, but does reduce the backward compatibility
risk to the minimum, so I guess it's the best course of action.

On Wed, Jan 6, 2010 at 7:20 PM, Blake Sullivan wrote:

>  OK.  I got smarter and looked more carefully at the FacesBean
> implementations. The best solution is to modify
> org.apache.myfaces.trinidadinternal.bean.UIXFacesBeanImpl to hang onto the
> UIXComponent passed to init() and then override setProperty(),
> getLocalPropertyImpl(), saveState(), and restoreState() to handle the id
> attribute by calling _component.getId()/setId() as appropriate.  No api
> changes and the change is encapsulated in UIXFacesBeanImpl and
> UIXComponentBase.
>
> -- Blake Sullivan
>
>
> \Simon Lessard said the following On 1/6/2010 10:40 AM PT:
>
> Hi Blake,
>
> Yep, that's exactly what I meant. I'm aware that the main risk lies with
> compatibility, but I think it's minimal.
>
>
> Regards,
>
> ~ Simon
>
> On Tue, Jan 5, 2010 at 8:00 PM, Blake Sullivan  
> wrote:
>
>
>
>   Simon Lessard said the following On 1/5/2010 2:34 PM PT:
>
> Blake,
>
> For 1, both possibilities exist. However, I would prefer them to not be
> available on the FacesBean from a performance PoV. Those don't have indexed
> property keys anyway so the lookup for them is actually quite inefficient.
> That would requires some additional changes to the state saving though.
>
>
>  Hmm.  I believe that FlaggedPropertyMap uses a HashMap to store these, so
> they aren't that bad.(this isn't necessarily the best choice for size
> reasons, but that's a separate issue)
>
> We are talking about optimization at the constant level--all proposed
> mechanism are O(1) in all cases right now.  The differences between the
> different proposals are:
>
>
>  1) Current
>  2) ValueExpression Proposal
>  3) Split AttributeMap and FacesBean (Simon's proposal A)
>  4) Simon's  Custom Properties in FacesBean-B
>   UIComponent.getFoo()
>  Flagged Map Access
>  Flagged Map Access Flagged Map Access Flagged Map Access  *
> UIComponent.getId()* *Map Access (since id always set)
> * *Direct
> * *Direct
> * *Direct*
>   FacesBean.getProperty(FOO_KEY)
>  Flagged Map Access Flagged Map Access Flagged Map Access
>
>  Flagged Map Access  *UIComponent.getAttributes().get("foo")
> * *2 Map Accesses* *2 Map Accesses* *2 Map Accesses (one flagged) and a
> reflection call
> * *2 Map Accesses (one flagged) and a reflection call*  *
> UIComponent.getAttributes().get("id")
> * *2 Map Accesses
> * *2 Map Accesses, 1 cast and  function call
> * *1 Map Access and reflection call
> * *1 Map Access and reflection call*  *UIComponent.getAttributes().get("custom
> foo")* *2 Map Accesses* *2 Map Accesses* *Map access
> * *2 Map Accesses (one flagged) and a reflection call*  *
> *I've bold-faced the rows that are actually different.
>
> The proposals also differ slightly with regards to whether the same values
> are available through the attributeMap, UIComponent direct accessor, and the
> FacesBean.  The current implementation makes all three of these identical.
> The ValueExpression does likewise.  In the split implementation custom
> attributes aren't available from the FacesBean.  In the custom properties
> case, proeprties that were optimized, wouldn't be available from the
> FacesBean, which may or may not be OK (some Renderer apis unfortunately only
> pass FacesBeans and not the UIComponent as well)
>
> Another option for speeding up attributes like getId(), would be to add a
> different flag to the PROPERTY_KEYS, requesting that the storage of this
> particular property be optimized.  Depending on how flexible the use of
> these keys needed to be, this could result in only the lowest keys being
> allowed to be optimized (so that one index would suffice), or adding a
> separate optimized index.  This would result in hybrid storage where the
> optimized keys were available for direct access from an array.  However,
> while this has some storage size advantages, I doubt it would actually be
> significantly faster than the current HashMap--the performance issue is
> really the work we do before we get to the HashMap.  In addition, this
> solution would not make it easier to add code to do extra work in order to
> handle, say clientId caching.
>
> I believe that 3) definitely and 4), potentially, have backwards
> compatibility issues.  My biggest complaints with 2) is that checking the
> extra flag is a little gross and is potentially make other attribute access
> slightly slower (though profiling doesn't show it).  The extra custom
> ValueExpression isn't

Re: [TRINIDAD][API]TRINIDAD-1668 Speed up UIXComponent.getId()

[Simon Lessard]

Hi Blake,

Yep, that's exactly what I meant. I'm aware that the main risk lies with
compatibility, but I think it's minimal.


Regards,

~ Simon

On Tue, Jan 5, 2010 at 8:00 PM, Blake Sullivan wrote:

>  Simon Lessard said the following On 1/5/2010 2:34 PM PT:
>
> Blake,
>
> For 1, both possibilities exist. However, I would prefer them to not be
> available on the FacesBean from a performance PoV. Those don't have indexed
> property keys anyway so the lookup for them is actually quite inefficient.
> That would requires some additional changes to the state saving though.
>
>
>  Hmm.  I believe that FlaggedPropertyMap uses a HashMap to store these, so
> they aren't that bad.(this isn't necessarily the best choice for size
> reasons, but that's a separate issue)
>
> We are talking about optimization at the constant level--all proposed
> mechanism are O(1) in all cases right now.  The differences between the
> different proposals are:
>
>
>  1) Current
>  2) ValueExpression Proposal
>  3) Split AttributeMap and FacesBean (Simon's proposal A)
>  4) Simon's  Custom Properties in FacesBean-B
>   UIComponent.getFoo()
>  Flagged Map Access
>  Flagged Map Access Flagged Map Access Flagged Map Access  *
> UIComponent.getId()* *Map Access (since id always set)
> * *Direct
> * *Direct
> * *Direct*
>   FacesBean.getProperty(FOO_KEY)
>  Flagged Map Access Flagged Map Access Flagged Map Access
>
>  Flagged Map Access  *UIComponent.getAttributes().get("foo")
> * *2 Map Accesses* *2 Map Accesses* *2 Map Accesses (one flagged) and a
> reflection call
> * *2 Map Accesses (one flagged) and a reflection call*  *
> UIComponent.getAttributes().get("id")
> * *2 Map Accesses
> * *2 Map Accesses, 1 cast and  function call
> * *1 Map Access and reflection call
> * *1 Map Access and reflection call*  *UIComponent.getAttributes().get("custom
> foo")* *2 Map Accesses* *2 Map Accesses* *Map access
> * *2 Map Accesses (one flagged) and a reflection call*  *
> *I've bold-faced the rows that are actually different.
>
> The proposals also differ slightly with regards to whether the same values
> are available through the attributeMap, UIComponent direct accessor, and the
> FacesBean.  The current implementation makes all three of these identical.
> The ValueExpression does likewise.  In the split implementation custom
> attributes aren't available from the FacesBean.  In the custom properties
> case, proeprties that were optimized, wouldn't be available from the
> FacesBean, which may or may not be OK (some Renderer apis unfortunately only
> pass FacesBeans and not the UIComponent as well)
>
> Another option for speeding up attributes like getId(), would be to add a
> different flag to the PROPERTY_KEYS, requesting that the storage of this
> particular property be optimized.  Depending on how flexible the use of
> these keys needed to be, this could result in only the lowest keys being
> allowed to be optimized (so that one index would suffice), or adding a
> separate optimized index.  This would result in hybrid storage where the
> optimized keys were available for direct access from an array.  However,
> while this has some storage size advantages, I doubt it would actually be
> significantly faster than the current HashMap--the performance issue is
> really the work we do before we get to the HashMap.  In addition, this
> solution would not make it easier to add code to do extra work in order to
> handle, say clientId caching.
>
> I believe that 3) definitely and 4), potentially, have backwards
> compatibility issues.  My biggest complaints with 2) is that checking the
> extra flag is a little gross and is potentially make other attribute access
> slightly slower (though profiling doesn't show it).  The extra custom
> ValueExpression isn't great, but on the other hand, it is essentially a
> minimal object--just an object with a back pointer to the component.  In
> addition, the size if far outweighed by our using a HashMap to store the
> properties (which I will come up with a proposal for fixing).  I agree that
> both 3) and 4) make it easier to optimize additional properties, rendered
> being the most important, however, not having rendered available from the
> FacesBean would almost certainly cause backwards compatibility problems
>
> Simon, does this correctly represent your proposals?  Essentially, I'm
> worried about the compatibility issues.
>
> -- Blake Sullivan
>
> So, we would have:
>
> For predefined properties:
> 1. Direct access:
> UIComponent.getX() --> FacesBean.getProperty(X_KEY)  ==> O(1), one indexed
> map loopkup
>
>

Re: [TRINIDAD][API]TRINIDAD-1668 Speed up UIXComponent.getId()

[Simon Lessard]

Blake,

For 1, both possibilities exist. However, I would prefer them to not be
available on the FacesBean from a performance PoV. Those don't have indexed
property keys anyway so the lookup for them is actually quite inefficient.
That would requires some additional changes to the state saving though.

So, we would have:

For predefined properties:
1. Direct access:
UIComponent.getX() --> FacesBean.getProperty(X_KEY)  ==> O(1), one indexed
map loopkup

2. FacesBean access (in renderers):
FacesBean.getProperty(X_KEY)  ==> O(1), one indexed map loopkup

3. Attribute map access:
UIComponent.getAttributes().get("x") --> UIComponent.getX() -->
FacesBean.getProperty(X_KEY)  ==> O(1), one hashed map lookup
(String.hashCode is cached), one reflection call, one indexed map loopkup

For custom properties:
3. Attribute map access:
UIComponent.getAttributes().get("x") ==> O(1), one hashed map lookup


If we keep setting the custom properties in FacesBean, then the AttributeMap
must also have a link to the FacesBean and the algorithm would be
Accessor accessor = getAccessor(propertyName);
if (accessor == null)
{
// custom property, use the faces bean directly
PropertyKey propertyKey = _bean.getType().findKey(propertyName);
if (propertyKey == null)
propertyKey = PropertyKey.createPropertyKey(propertyName);

return _bean.getProperty(propertyKey);
}
else
{
// predefined property
return accessor.get(component);
}

private Accessor getAccessor(String propertyName)
{
// Using an accessor cache should be required, sadly Method is not
Serializable,
// but it would still be possible to cache it in a semi static
ClassLoaderLocal Map, Map> ...
}

private static class Accessor
{
private Method getter;
private Method setter;
private Class type;

public Object get(Object o)
{
return getter.invoke(o);
}

// ...
}


Regards,

~ Simon

On Tue, Jan 5, 2010 at 4:31 PM, Blake Sullivan wrote:

>  Simon,
>
> For part 1), are you proposing that we stop overriding getAttributes()?  If
> so, private implementation properties used by the component and set by using
> setAttribtue(), would not be available on the FacesBean.  So I assume that
> you are suggesting that we change the components to set these on the
> FacesBean directly in these cases.
>
> I did a quick grep and the components and they are using the attributeMap.
> It is unclear how many of these would be left if we removed all of the cases
> where the direct accessor could be used, and the cases where we would switch
> to direct FacesBean access, however these case do suffer from the worst of
> all worlds as far as performance, since the pay the cost of both reflection
> and Map access.
>
> -- Blake Sullivan
>
>
> Simon Lessard said the following On 1/5/2010 12:32 PM PT:
>
> Hi Blake,
>
> Actually it's harsher/simpler than that. Assuming that .getAttributes() is
> very rarely used in a Trinidad application (exception for custom
> attributes).
>
> 1. Have AttributeMap work exactly like standard JSF's AttributeMap. That is,
> always call the getter/setter on the component (which in turn will use the
> FacesBean if needed). For custom properties, they could either be stored in
> the FacesBean or on the component itself
> 2. Handle the id attribute manually for state saving purposes in
> UIXComponentBase
>
> Point 1. does impact performances vs. direct FacesBean access when accessing
> defined properties, but all Trinidad applications most likely directly use
> FacesBean.getProperty(PropertyKey) directly, like all our renderer do. For
> custom properties, there's absolutely no hit.
>
>
> Regards,
>
> ~ Simon
>
> On Tue, Jan 5, 2010 at 3:24 PM, Blake Sullivan  
> wrote:
>
>
>
>   Is your suggestion that we
> 1) Add a new Map(String, Object>) implementation that takes both the
> FacesBean and the UIComponent
> 2) Explicitly test for the id attribute in all of the accessor and mutator
> functions, in addition to the the Sets returned
> 3) Override the state saving/restoration  code to explicitly handle id
>
> -- Blake Sullivan
>
> Simon Lessard said the following On 1/5/2010 12:08 PM PT:
>
> Have the AttributeMap call the getId/setId. The contract for the Map
> returned by getAttributes is supposed to call the getter/setter method on
> the component anyway, 
> fromhttp://java.sun.com/javaee/5/docs/api/javax/faces/component/UIComponent.html#getAttributes%28%29
> :
>
>
>
>
> - get() - If the property is readable, call the getter method and
>return the returned value (wrapping primitive values in their corresponding
>wrapper classes); otherwise throw IllegalArgumentException.
>- put() - If the property is writea

Re: [TRINIDAD][API]TRINIDAD-1668 Speed up UIXComponent.getId()

[Simon Lessard]

Hi Blake,

Actually it's harsher/simpler than that. Assuming that .getAttributes() is
very rarely used in a Trinidad application (exception for custom
attributes).

1. Have AttributeMap work exactly like standard JSF's AttributeMap. That is,
always call the getter/setter on the component (which in turn will use the
FacesBean if needed). For custom properties, they could either be stored in
the FacesBean or on the component itself
2. Handle the id attribute manually for state saving purposes in
UIXComponentBase

Point 1. does impact performances vs. direct FacesBean access when accessing
defined properties, but all Trinidad applications most likely directly use
FacesBean.getProperty(PropertyKey) directly, like all our renderer do. For
custom properties, there's absolutely no hit.


Regards,

~ Simon

On Tue, Jan 5, 2010 at 3:24 PM, Blake Sullivan wrote:

>  Is your suggestion that we
> 1) Add a new Map(String, Object>) implementation that takes both the
> FacesBean and the UIComponent
> 2) Explicitly test for the id attribute in all of the accessor and mutator
> functions, in addition to the the Sets returned
> 3) Override the state saving/restoration  code to explicitly handle id
>
> -- Blake Sullivan
>
> Simon Lessard said the following On 1/5/2010 12:08 PM PT:
>
> Have the AttributeMap call the getId/setId. The contract for the Map
> returned by getAttributes is supposed to call the getter/setter method on
> the component anyway, 
> fromhttp://java.sun.com/javaee/5/docs/api/javax/faces/component/UIComponent.html#getAttributes%28%29
> :
>
>
>
>
> - get() - If the property is readable, call the getter method and
>return the returned value (wrapping primitive values in their corresponding
>wrapper classes); otherwise throw IllegalArgumentException.
>- put() - If the property is writeable, call the setter method to set
>the corresponding value (unwrapping primitive values in their corresponding
>wrapper classes). If the property is not writeable, or an attempt is made 
> to
>set a property of primitive type to null, throw
>IllegalArgumentException.
>
>
>
>
>  Regards,
>
> ~ Simon
>
>
> On Tue, Jan 5, 2010 at 2:50 PM, Blake Sullivan  
> wrote:
>
>
>
>   The reason is that we need to support AttributeMap/component accessor
> equivalence--get/set of the id attribute through the Map is supposed to work
> correctly.  The ValueExpression only exists to make this work.
>
> -- Blake Sullivan
>
> Simon Lessard said the following On 1/5/2010 10:57 AM PT:
>
> Hi,
>
> Why not simply NOT support a PropertyKey for the id attribute? I know it
> isn't consistent with the other properties, but id is a very special case
> not supporting EL anyway. In all the project I ever did, I never used
> FacesBean.getProperty(ID_
> PROPERTY_KEY). The only drawback I would see is if
> the component's id actually need to be read in a property getter method in a
> renderer which receive only the FacesBean instance and not the component
> itself. That would be much faster than a custom ValueExpression and the
> memory footprint would also be better.
>
> Regards,
>
> ~ Simon
>
> On Tue, Jan 5, 2010 at 1:49 PM, Matthias Wessendorf  
>   wrote:
>
>
>
>  On Thu, Dec 31, 2009 at 11:12 PM, Blake Sullivan 
>   
>  wrote:
>
>
>  UIComponent.getId() is by far the most requested component attribute.
>
>
>   There
>
>
>  are a number of reasons for this:
> 1) The JSF RI has an issue in the JSP-JSF integration which causes
>
>
>  getId()
>
>
>  to be called n^2 times where n is the number of children a component has
>
>
>  I guess this is true for MyFaces as well, right?
>
>
>
>  2) getClientId() calls getId()
> 3) FindComponent calls getId()
> 4) The tree visiting code trades off calls to getClientId() for calls to
> getId()
>
> FacesBean optimizes attribute Map access at the expense of access
>
>
>  directly
>
>
>  through the component.  The the extent that Renderers are Components are
> accessing the attributes through the attribute Map, this is fine, however
> even the Renderers access attributes common to all UIComponents such as
>
>
>  id()
>
>
>  through the component directly.  Considering the huge number of times
>
>
>  that
>
>
>  the the id is accessed (for some renders, this was 8% of the rendering
> time), it makes sense to optimize this path.
>
> The proposal is to:
> 1) Store the id an an instance variable on the UIXComponent
> 2) Add a new capability flag to PropertyKey indicating that the property
>
>
>  is
>
>
>  actually stored elsewhere using a ValueExpression will be store

Re: [TRINIDAD][API]TRINIDAD-1668 Speed up UIXComponent.getId()

[Simon Lessard]

Have the AttributeMap call the getId/setId. The contract for the Map
returned by getAttributes is supposed to call the getter/setter method on
the component anyway, from
http://java.sun.com/javaee/5/docs/api/javax/faces/component/UIComponent.html#getAttributes%28%29
:


>- get() - If the property is readable, call the getter method and
>return the returned value (wrapping primitive values in their corresponding
>wrapper classes); otherwise throw IllegalArgumentException.
>- put() - If the property is writeable, call the setter method to set
>the corresponding value (unwrapping primitive values in their corresponding
>wrapper classes). If the property is not writeable, or an attempt is made 
> to
>set a property of primitive type to null, throw
>IllegalArgumentException.
>
>

Regards,

~ Simon


On Tue, Jan 5, 2010 at 2:50 PM, Blake Sullivan wrote:

>  The reason is that we need to support AttributeMap/component accessor
> equivalence--get/set of the id attribute through the Map is supposed to work
> correctly.  The ValueExpression only exists to make this work.
>
> -- Blake Sullivan
>
> Simon Lessard said the following On 1/5/2010 10:57 AM PT:
>
> Hi,
>
> Why not simply NOT support a PropertyKey for the id attribute? I know it
> isn't consistent with the other properties, but id is a very special case
> not supporting EL anyway. In all the project I ever did, I never used
> FacesBean.getProperty(ID_PROPERTY_KEY). The only drawback I would see is if
> the component's id actually need to be read in a property getter method in a
> renderer which receive only the FacesBean instance and not the component
> itself. That would be much faster than a custom ValueExpression and the
> memory footprint would also be better.
>
> Regards,
>
> ~ Simon
>
> On Tue, Jan 5, 2010 at 1:49 PM, Matthias Wessendorf  
> wrote:
>
>
>
>  On Thu, Dec 31, 2009 at 11:12 PM, Blake Sullivan 
>  wrote:
>
>
>  UIComponent.getId() is by far the most requested component attribute.
>
>
>   There
>
>
>  are a number of reasons for this:
> 1) The JSF RI has an issue in the JSP-JSF integration which causes
>
>
>  getId()
>
>
>  to be called n^2 times where n is the number of children a component has
>
>
>  I guess this is true for MyFaces as well, right?
>
>
>
>  2) getClientId() calls getId()
> 3) FindComponent calls getId()
> 4) The tree visiting code trades off calls to getClientId() for calls to
> getId()
>
> FacesBean optimizes attribute Map access at the expense of access
>
>
>  directly
>
>
>  through the component.  The the extent that Renderers are Components are
> accessing the attributes through the attribute Map, this is fine, however
> even the Renderers access attributes common to all UIComponents such as
>
>
>  id()
>
>
>  through the component directly.  Considering the huge number of times
>
>
>  that
>
>
>  the the id is accessed (for some renders, this was 8% of the rendering
> time), it makes sense to optimize this path.
>
> The proposal is to:
> 1) Store the id an an instance variable on the UIXComponent
> 2) Add a new capability flag to PropertyKey indicating that the property
>
>
>  is
>
>
>  actually stored elsewhere using a ValueExpression will be stored as the
> property's value in the PropertyMap.  For access through the FacesBean,
>
>
>  the
>
>
>  ValueExpression will be evaluated to get/set the actual value
> 3) For state saving the ValueExpression is used to retrieve the actual
>
>
>  value
>
>
>  and for state restoration the ValueExpression (which has been
>
>
>  rebootstrapped
>
>
>  by the UIXComponent) is used to write the value back
> 4) Instead of setting the id attribute in the FacesBean, UIXComponent
>
>
>  stores
>
>
>  it locally and sets an ValueExpression implementation into the FacesBean
> that retrieves the value from the UIXComponent
>
>
>  +1 on api/patch
>
>
>
>  API Changes:
>
> PropertyKey:
>
> add
>
>  /**
>  * Capability indicating that values for this property should be
>  * be stored and retrieved through a ValueExpression rather than on the
>  * FacesBean itself
>  */
>  static public final int CAP_VALUE_EXPRESSION_IMPLEMENTATION = 16;
>
>  /**
>  * Returns true if property values for this key are set and
>
>
>  get
>
>
>   * using a ValueExpression rather than storing the value in the
>
>
>  FacesBean.
>
>
>   * @return true if properties values for this key are
>
>
>  retrieved
>
>
>   * with a ValueExpression.
>  */
>  public boolean usesValueExpressionAsImplementation()
>
> After this change id retrieval doesn't make the 1% YourKit profiler hot
>
>
>  spot
>
>
>  cut off
>
>
>
>
>
>  --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
>

Re: [TRINIDAD][API]TRINIDAD-1668 Speed up UIXComponent.getId()

[Simon Lessard]

Hi,

Why not simply NOT support a PropertyKey for the id attribute? I know it
isn't consistent with the other properties, but id is a very special case
not supporting EL anyway. In all the project I ever did, I never used
FacesBean.getProperty(ID_PROPERTY_KEY). The only drawback I would see is if
the component's id actually need to be read in a property getter method in a
renderer which receive only the FacesBean instance and not the component
itself. That would be much faster than a custom ValueExpression and the
memory footprint would also be better.

Regards,

~ Simon

On Tue, Jan 5, 2010 at 1:49 PM, Matthias Wessendorf wrote:

> On Thu, Dec 31, 2009 at 11:12 PM, Blake Sullivan
>  wrote:
> > UIComponent.getId() is by far the most requested component attribute.
>  There
> > are a number of reasons for this:
> > 1) The JSF RI has an issue in the JSP-JSF integration which causes
> getId()
> > to be called n^2 times where n is the number of children a component has
>
> I guess this is true for MyFaces as well, right?
>
> > 2) getClientId() calls getId()
> > 3) FindComponent calls getId()
> > 4) The tree visiting code trades off calls to getClientId() for calls to
> > getId()
> >
> > FacesBean optimizes attribute Map access at the expense of access
> directly
> > through the component.  The the extent that Renderers are Components are
> > accessing the attributes through the attribute Map, this is fine, however
> > even the Renderers access attributes common to all UIComponents such as
> id()
> > through the component directly.  Considering the huge number of times
> that
> > the the id is accessed (for some renders, this was 8% of the rendering
> > time), it makes sense to optimize this path.
> >
> > The proposal is to:
> > 1) Store the id an an instance variable on the UIXComponent
> > 2) Add a new capability flag to PropertyKey indicating that the property
> is
> > actually stored elsewhere using a ValueExpression will be stored as the
> > property's value in the PropertyMap.  For access through the FacesBean,
> the
> > ValueExpression will be evaluated to get/set the actual value
> > 3) For state saving the ValueExpression is used to retrieve the actual
> value
> > and for state restoration the ValueExpression (which has been
> rebootstrapped
> > by the UIXComponent) is used to write the value back
> > 4) Instead of setting the id attribute in the FacesBean, UIXComponent
> stores
> > it locally and sets an ValueExpression implementation into the FacesBean
> > that retrieves the value from the UIXComponent
>
> +1 on api/patch
>
> >
> > API Changes:
> >
> > PropertyKey:
> >
> > add
> >
> >  /**
> >  * Capability indicating that values for this property should be
> >  * be stored and retrieved through a ValueExpression rather than on the
> >  * FacesBean itself
> >  */
> >  static public final int CAP_VALUE_EXPRESSION_IMPLEMENTATION = 16;
> >
> >  /**
> >  * Returns true if property values for this key are set and
> get
> >  * using a ValueExpression rather than storing the value in the
> FacesBean.
> >  * @return true if properties values for this key are
> retrieved
> >  * with a ValueExpression.
> >  */
> >  public boolean usesValueExpressionAsImplementation()
> >
> > After this change id retrieval doesn't make the 1% YourKit profiler hot
> spot
> > cut off
> >
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: alternate view-handler in MyFaces-2.0.0-alpha

[Simon Lessard]

Hi,

The context parameter is the way to go, but it might not be working yet in
MyFaces alpha.


~ Simon

On Fri, Dec 25, 2009 at 10:21 PM, Mark Struberg  wrote:

> Hi!
>
> Since RichFaces-3.3.3 is not compatible with the builtin JSF-2.0 facelets 2
> version, I need to disable it and configure  the 'old' facelets-1.1.15.B1
> manually.
>
> After digging the whole night, I still couldn't find out how to do this
> with MyFaces. In Mojarra it now works with:
>
> in web.xml:
> 
>javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
>true
> 
>
> and in faces-config.xml:
> 
>com.sun.facelets.FaceletViewHandler
> 
>
>
> As far as I can see from the JSF-2 spec, this configuration should still be
> supported:
> >  /faces-config/application/view-handler -- Replace the default
> ViewHandler instance with the one specified. The
> > contents of this element must be a fully qualified Java class name that,
> when instantiated, is a ViewHandler.
>
> but looking at ViewDeclarationLanguageFactoryImpl doesn't show anything
> which looks alike.
>
> How to disable the internal facelets-2 and enable the 'old' facelets-1.1.15
> in MyFaces?
>
> txs and LieGrue,
> strub
>
>
> __
> Do You Yahoo!?
> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
> gegen Massenmails.
> http://mail.yahoo.com
>

Re: [JSF 2.0] Moving ViewDeclairationLanguage Impl's to shared

[Simon Lessard]

Hi,

Although I wouldn't mind if this is needed, I do find it weird for the
portle bridge to work with the VDL at all. VDL is supposed to have pretty
much a single purpose: convert a physical document to a JSF component tree.
That being said the JSP VDL most likely uses Servlet API too since, well,
it's about the only way to interact with JSP. This is sad, make you wish JSP
was never supported for JSF...


~ Simon

On Fri, Dec 18, 2009 at 1:38 AM, Matthias Wessendorf wrote:

> On Thu, Dec 17, 2009 at 11:42 PM, Scott O'Bryan 
> wrote:
> > It's going to be JSF 2.0/Portal 2.0.  I'm not sure if the JCP is going to
> > look at a Portal 1.0 Spec for JSF 2.0.  The leanings on the current EG's
> > were that they were not.  Portal 1.0 has some pretty major issues in
> dealing
> > with AJAX and whatnot so such a specification would be problematic.
>
> even due to the fact that I am mostly a portlet ignorant, this makes sense
> to only specify Portlet 2.0 w/ JSF 2
>
> >
> > As for the VDL, simply put the current JSP VDL casts to some servlet
> objects
> > (at least in the R.I.) to do some things.  ;)  ClassCastExceptions
> do
> > not an effective bridge make..
>
> Not to surprised if myfaces does that too. Filing bugs is welcome.
> Note that Apache MyFaces 2.0 is already alpha and we are not too
> far away from a real release...
>
> >
> > The current bridge overrides the ViewHandler.renderView to overcome this
> > problem, but I thought it might be nice to synchronize some code up.  As
> it
> > is right now, I'm merging the code from the ViewHandler.renderView in the
> > Portlet 2.0 bridge with the current R.I.   There are some strange issues
> > which I'm overcoming, but evenutally it might be nice to allow MyFaces
> > development to continue to drive these view handlers.
>
> sharing is good. So you are basically suggesting to reuse the
> ViewDeclarationLanguage from
> MyFaces (including ViewDeclarationLanguageBase and
> ViewDeclarationLanguageStrategy) and make them part of the shared
> project ?
>
> -Matthias
>
> >
> > 
> >
> > Just a thought..
> >
> > Scott
> >
> > Ganesh wrote:
> >>
> >> Cool, you're working on this. Just a week ago I was stuck with
> >> the current portal - JSF2.0 problem. Are you doing portal 1.0 -
> >> JSF 2.0 or portal 2.0 - JSF 2.0?
> >>
> >> I not yet clear about why the bridge needs to care about the
> >> VDL. I thought it would suffice to brige the portal lifecyle
> >> phases and forward the requests to the faces servlet?
> >>
> >> Best regards,
> >> Ganesh
> >>
> >> Scott O'Bryan schrieb:
> >>>
> >>> Hey Guys,
> >>>
> >>> I'm working on a preliminary version of the portlet-bridge for JSF2.0..
> >>>  Looking at the current R.I. implementations, it appears as if I'm
> going to
> >>> have to come up with my own implementations for the
> >>> ViewDeclairationLanguage's for the bridge.  Although the R.I. is laid
> out so
> >>> that their implementations of the ViewDeclairationLanguage's is easily
> >>> extended, everything is impl.  Since the Portlet Bridge is an Apache
> project
> >>> and should be container agnostic, I'm basically stuck with two choices:
> >>>
> >>>   1. Write the bridge's own implementation of the
> >>>  ViewDeclairationLanguage for both JSF and facelets, or
> >>>   2. Just use/extend the ViewDeclairationLanguage for MyFaces from the
> >>>  shared project
> >>>
> >>> I would rather do the latter so that the implementations of the
> >>> ViewDeclairationLanguage becomes consistent and, ideally, would allow
> us to
> >>> work with both the R.I. and MyFaces (albeit with the MyFaces code
> handling
> >>> the ViewDeclairationLanguage in the portal.
> >>>
> >>> Any preferences or comments of the feasibility of implementing this?  I
> >>> haven't looked at this in depth but wanted to gauge people's reactions
> >>> before I went too far down the rabbit hole.
> >>>
> >>> Scott
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: [Trinidad 2.0] introducing ProjectStage API

[Simon Lessard]

Looks good to me as well. I've got to admit that this ProjectStage thing
seems to get more useful than what I was thinking when I first saw it pop on
the EG list

On Thu, Dec 10, 2009 at 1:12 PM, Matthias Wessendorf wrote:

> awesome.
>
> I plan to start development on that next week... Till than you can
> change your mind :-)
>
> -Matthias
>
> On Thu, Dec 10, 2009 at 7:08 PM, Jeanne Waldman
>  wrote:
> > I agree with your list Matthias.
> > Jeanne
> >
> > Matthias Wessendorf wrote, On 12/8/2009 8:56 AM PT:
> >
> > http://wiki.apache.org/myfaces/Trinidad_goes_ProjectStage
> >
> > On Tue, Dec 8, 2009 at 5:54 PM, Matthias Wessendorf 
> > wrote:
> >
> >
> > ok,
> >
> > I updated the wiki:
> >
> > I will continue with these values, as there was no concern against them.
> >
> > regarding the hidden, unspecified
> > "javax.faces.FACELETS_REFRESH_PERIOD" parameter, I will follow up in
> > a different thread.
> >
> > -Matthias
> >
> > On Wed, Dec 2, 2009 at 9:06 PM, Matthias Wessendorf 
> > wrote:
> >
> >
> > On Wed, Dec 2, 2009 at 8:52 PM, Pavitra Subramaniam
> >  wrote:
> >
> >
> > "Matthias Wessendorf wrote:" On 12/2/2009 10:43 AM PT:
> >
> > Ok,
> >
> > I added some value suggestions to those guys that we identified to fit
> > into the ProjectStage API:
> >
> >
> > -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT
> >  * Production => FALSE
> >  * other stages => TRUE
> >
> >
> > +1. although I think if a user were to change the recommended defaults,
> like
> > set ProjectStage=Production and override the DEBUG_JS to be true, then we
> at
> > least need to warn the user of this as appropriate.
> >
> >
> > Yeah I was planing do WARNING for everything that is overridden
> >
> >
> >
> > -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION
> >  * Production => FALSE
> >  * other stages => TRUE
> > -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION
> >  * Production => FALSE
> >  * other stages => TRUE
> > -org.apache.myfaces.trinidad.resource.DEBUG
> >  * Production => FALSE
> >  * other stages => TRUE
> > -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (see above)
> >  * Production => FALSE (current default)
> >  * other stages => TRUE
> > - (from trinidad-config.xml file)
> >  * Production => FALSE
> >  * other stages => TRUE
> >
> >
> > +1. I also was wondering if
> > "org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION" should be set to
> > NONE in Production if this is really used for a testing Trinidad in
> > pseudo-High Availability (HA) mode. It looks like we could set this
> > different values based on the the ProjectStage
> >
> > Production
> > org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=none
> >
> > Development, Unit Test
> > org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree
> >
> > System Test
> > org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all
> >
> >
> > great. thanks for the feedback. Makes sense to me. I think that this
> > parameter actually *translates* to the ProjectStage.
> > Your suggestions make sense to me.
> >
> > -Matthias
> >
> >
> >
> >
> > -Pavitra
> >
> > Please let me know what you think...
> >
> >
> > I updated the wiki page, to reflect the suggestions:
> > http://wiki.apache.org/myfaces/Trinidad_goes_ProjectStage
> >
> > I also created this JIRA ticket, to keep track of the item:
> > https://issues.apache.org/jira/browse/TRINIDAD-1652
> >
> > -Matthias
> >
> > On Wed, Dec 2, 2009 at 3:18 PM, Matthias Wessendorf 
> > wrote:
> >
> >
> > yep, that's what I was saying
> >
> > On Wed, Dec 2, 2009 at 3:04 PM, Jakob Korherr 
> > wrote:
> >
> >
> > Hi,
> >
> > I think the best way would be that the init parameters have stage related
> > standard values (actually that what Matthias suggested), for example:
> >
> > If we are in ProjectStage.Production the standard value of
> > org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION is false,
> otherwise
> > it is true.
> >
> > But this only sets the DEFAULT value. The user still can configure each
> > parameter independently by putting it in web.xml.
> >
> > Regards
> >
> > Jakob Korherr
> >
> > 2009/12/2 Martin Koci 
> >
> >
> > Hi,
> >
> > does trinidad reload both JSP and facelets views if
> > org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION=true?
> >
> > For facelets based views there is a new JSF 2.0 param
> > javax.faces.FACELETS_REFRESH_PERIOD (-1 = never reload, 0=always, 1,2,
> > 3,.. - check interval) but it's relation to project stage is not clear -
> > see https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434
> >
> > Martin Kočí
> >
> > Matthias Wessendorf píše v St 02. 12. 2009 v 09:25 +0100:
> >
> >
> > Hi,
> >
> > here is a (complete?) list of all Trinidad configuration parameters:
> >
> > * System Properties ( => System.getProperty()):
> > org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION
> > documentation is here:
> > http://issues.apache.org/jira/browse/TRINIDAD-1245
> >
> >
> http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces

Re: [MyFaces 2] Multiple children in facet

[Simon Lessard]

Hi,

I'm pretty sure this was discussed on the EG list, so yeah it looks like a
hole in the spec and Mojarra being right here.


~ Simon

On Mon, Nov 30, 2009 at 6:28 PM, Michael Kurz  wrote:

> Hi,
>
> I have recently created a bunch of applications with Mojarra 2.0 that I'm
> currently trying to port to MyFaces 2.0.
>
> In Mojarra 2 it is possible to have more than one child in a facet (without
> enclosing them in a panel). So I thought this is part of the new spec. But
> when I noticed that this is not working in MyFaces 2.0 I checked the spec
> and found no such feature.
>
> Did I miss something, or is this a Mojarra-specific feature?
>
> regards
> Michael Kurz
>

Re: [VOTE] release of myfaces core 2.0.0-alpha

[Simon Lessard]

+1

On Wed, Nov 25, 2009 at 9:39 AM, Michael Concini  wrote:

> +1
>
>
> Bruno Aranda wrote:
>
>> +1
>>
>> 2009/11/25 Cagatay Civici :
>>
>>
>>> +1
>>>
>>> On Wed, Nov 25, 2009 at 2:20 PM, Matthias Wessendorf 
>>> wrote:
>>>
>>>
 +1

 On Wed, Nov 25, 2009 at 2:27 PM, Jakob Korherr >>> >
 wrote:


> +1
>
> 2009/11/25 Leonardo Uribe 
>
>
>> Hi,
>>
>> I was running the needed tasks to get the 2.0.0-alpha release of
>> Apache
>> MyFaces core out.
>>
>> Please note that this vote concerns all of the following parts:
>>  1. Maven artifact group "org.apache.myfaces.shared" v4.0.1-alpha  [1]
>>  2. Maven artifact group "org.apache.myfaces.test" v1.0.0-alpha [1]
>>  3. Maven artifact group "org.apache.myfaces.core" v2.0.0-alpha  [1]
>>
>> The artifacts are deployed to my private Apache account ([1] and [3]
>> for binary and source packages).
>>
>> The release notes could be found at [4].
>>
>> Also the clirr test does not show binary incompatibilities with
>> myfaces-api.
>>
>> Please take a look at the "2.0.0-alpha" artifacts and vote!
>>
>> Please note: This vote is "majority approval" with a minimum of three
>>  +1 votes (see [3]).
>>
>> 
>> [ ] +1 for community members who have reviewed the bits
>> [ ] +0
>> [ ] -1 for fatal flaws that should cause these bits not to be
>> released,
>>  and why..
>> 
>>
>> Thanks,
>> Leonardo Uribe
>>
>> [1] 
>> http://people.apache.org/~lu4242/myfaces200alpha
>>  [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>> [3] 
>> http://people.apache.org/~lu4242/myfaces200alphabinsrc
>>  [4]
>>
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&styleName=Html&version=12313389
>>
>>
>
>

 --
 Matthias Wessendorf

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


>>>
>>>
>>
>>
>>
>
>

Re: [jsf 2.0] UIViewRoot afterPhase

[Simon Lessard]

Hi Jakob,

Because after restore view is actually one of the most used (along with
before render) and was specifically added to 2.0 for that purpose. It's not
possible to make it different because the spec say so, and thus MyFaces
might not pas the TCK if it was made differently. So, there's absolutely
nothing to do about it except raise the issue to the EG. But, as you
mentioned, the before restore is pretty much impossible since the attribute
is not yet restored.


Regards,

~ Simon

On Tue, Oct 27, 2009 at 5:07 PM, Jakob Korherr wrote:

> Hi,
>
> While working on MYFACES-2374 "UIViewRoot.getBeforePhaseListener() and
> UIViewRoot.getAfterPhaseListener() could be called on PhaseId.RESTORE_VIEW",
> I found out that the mojarra javadoc was changed, so that only
> UIViewRoot.getAfterPhaseListener should be called on RESTORE_VIEW.
>
> Mojarra javadoc on UIViewRoot.setAfterPhaseListener says: "Allow an
> arbitrary method to be called for the "afterPhase" event as the UIViewRoot
> runs through its lifecycle. This method will be called for all phases
> including PhaseId.RESTORE_VIEW."
> Just a week ago UIViewRoot.setBeforePhaseListener also said "...for all
> phases including PhaseId.RESTORE_VIEW.", now it says "...except
> PhaseId.RESTORE_VIEW."
>
> It is clear to me, why this was changed, because you have to restore the
> view before you can access the attributes, not really difficult to see.
> But why should we still call UIViewRoot.getAfterPhaseListener on
> RESTORE_VIEW?
>
> Spec says that we should only call an afterPhase method, if the relating
> beforePhase method returned without an Exception. Of course, these
> attributes of UIViewRoot are different to its "normal" PhaseListeners, but I
> think that this behaviour is kind of strange.
> Why don't we change it back to the way it was in jsf 1.2? So that
> UIViewRoot.getBeforePhaseListener AND UIViewRoot.getAfterPhaseListener are
> called for all phases except RESTORE_VIEW.
>
> Also: Mojarra 2.0.1 does not call UIViewRoot.setAfterPhaseListener on
> RESTORE_VIEW.
>
> Thanks in advance.
>
> Regards
>
> Jakob Korherr
>

Re: Custom component with children - Child component added dynamically at end appears as first child when rendered

[Simon Lessard]

Hi,

This is a good explanation. Is it possible for you to test a JSP version? To
be honest, I'm a bit flabbergasted to see something like that happen in
Facelet. Can you check the state of the component's children within the
formSubmitted method?

~ Simon

On Tue, Oct 27, 2009 at 11:43 AM,  wrote:

>
> OK. Here is a highly simplified case of the problem (source included):
>
> The custom component 'repeat' will simply iterate through its children and
> renders them.
>
> *Usage:*
>
> 
> 
> 
> 
>
>
> *Renderer output:*
>
> [begin - Child-1Child-2 - end]
>
>
> *BackingBean:*
>
> The repeat component is bounded to a backing bean like so:
>
> *public* *class* TestBean {
>
> *private* HtmlRepeat htmlRepeat;
>
> *public* HtmlRepeat getHtmlRepeat() {
> *return* *null*;
> }
>
> *public* *void* setHtmlRepeat(HtmlRepeat htmlRepeat) {
> *this*.htmlRepeat = htmlRepeat;
> }
>
> // -- action method
> *public* String formSubmitted() {
> System.*out*.println("formSubmitted()");
>
> HtmlOutputText child = *new* HtmlOutputText();
> child.setValue("Child-3");
> htmlRepeat.getChildren().add(child);
>
> *return* *null*;
> }
> }
>
> and the form is submitted using <*h:commandButton* value=*"Submit"* action
> ="#{testBean.formSubmitted}"/>
>
> The formSubmitted() method simply adds a child to htmlRepeat like so
> htmlRepeat.getChildren().add(child). Note that the child is added as the
> last child to the children list. But when the response is renderered, the
> newly added child appears at the beginning.
>
> *Expected Output:*
> ** [begin - Child-1Child-2Child-3 - end]
>
> *Actual Output:*
> ** [begin - Child-3Child-1Child-2 - end]
>
> *Attachments:*
>
> 1. jsf-repeat.jar - Deployable JSF component packaged as jar (contains
> .java files, faces-config.xml and facelet taglib for the custom component).
>
> Download >> http://keerthi.linux.googlepages.com/jsf-repeat.jar
>
> 2. TestRepeat.xhtml - Facelet view using the  custom
> component
>
> Download >> http://keerthi.linux.googlepages.com/TestRepeat.xhtml
>
> *Note:* The component requires facelets and so no TLD has been defined.
> Tested on myfaces1.2.6/Tomcat 6.20
>
>

Re: Custom component with children - Child component added dynamically at end appears as first child when rendered

[Simon Lessard]

Ugh, it should work fine... It looks like the base tag code fail to detect
that the component already exists when rereading the JSP... You use jsp
right? not facelet?

~ Simon

On Tue, Oct 27, 2009 at 10:17 AM,  wrote:

>
> Hi,
>
> The formSubmitted() is an action on a command button like this:
>
> <*h:commandButton* value=*"Submit"* action
> ="#{testBean.formSubmitted}"/>
>
> Thanks.
>
>
>  *Simon Lessard *
>
> 10/27/2009 07:43 PM
>   Please respond to
> "MyFaces Development" 
>
>   To
> MyFaces Development 
> cc
>   Subject
> Re: Custom component with children - Child component added
> dynamically at end appears as first child when rendered
>
>
>
>
> Hi,
>
> Yes I was, and it does seem correctly done too... Who's in charge of
> calling the formSubmitted method? Is is an action on a commandLink/Button?
>
> On Tue, Oct 27, 2009 at 9:56 AM, 
> <*kpanneersel...@inautix.co.in*>
> wrote:
>
> Hi Simon,
> Thanks for responding. I'm not quite sure what you mean by getter
> code for the navigation bar. Are you asking about the getter/setter for the
> navigation bar in my backing bean?
> *
> public* *class* TestBean {
>
> *private* HtmlNavigationBar navigationBar;
>
> *public* HtmlNavigationBar getNavigationBar() {
> *return* *null*;
> }
>
> *public* *void* setNavigationBar(HtmlNavigationBar navigationBar)
> {
> *this*.navigationBar = navigationBar;
> }
> }
>
> Thanks.
>
>   *Simon Lessard <**simon.lessar...@gmail.com* 
> *>*
>
> 10/27/2009 07:13 PM
>
>
>   Please respond to
> "MyFaces Development" <*...@myfaces.apache.org* >
>
>   To
> MyFaces Development <*...@myfaces.apache.org* >
> cc
>   Subject
> Re: Custom component with children - Child component added
> dynamically at end appears as first child when rendered
>
>
>
>
>
>
> Hi Keerthi,
>
> Can you post your getter code for the navigation bar please? Make sure it
> simply return null. My hunch is that your backing bean acts also as the
> component factory (which can incredibly bad).
>
>
> p.s. This post belong to the user list. Dev lists on Apache are for those
> developing the product. You may be a developer, but from Apache MyFaces
> perspective, you're an user.
>
>
> Regards,
>
> ~ Simon
>
> On Tue, Oct 27, 2009 at 9:31 AM, 
> <*kpanneersel...@inautix.co.in*>
> wrote:
>
> I have a custom JSF component that renders navigation links. The following
> is a typical usage of the component:
>
>  actionListener="#{testBean.navigationLinkClicked}" immediate="true"
> binding="#{testBean.navigationBar}">
> 
>  active="true"/>
> 
>
> 
> 
>  clickable="false"/>
>  clickable="false"/>
> 
>
> And, the rendered content will appear as following:
>
> Primary Data | Principals | Administrators | Custodiams | Accounting Firms
> | Law Firms | Billing
>
>
> As you notice, the navigationBar component is bounded to
> #{testBean.navigationBar} which is defined as below in the Backing bean:
>
> public class TestBean {
>
> private HtmlNavigationBar navigationBar;
>  // -- getter & setter for navigationBar
>
> public String formSubmitted() {
> HtmlNavigationLink link = new HtmlNavigationLink();
> link.setId("link");
> link.setValue("New link");
>
> navigationBar.getChildren().add(link)
>
> return null;
> }
> }
>
>
> The backing bean has an action method formSubmitted() that adds a child
> (HtmlNavigationLink) component to the parent (HtmlNavigationBar)
> dynamically. This method is invoked on form submit. I thought that this
> newly added child would be the last child (as it was added to end of the
> children list). But, when the navigationBar renders its children, the
> HtmlNavigationLink 'New link' appears as the first child causing the content
> rendered as below:
>
>
> New Link | Primary Data | Principals | Administrators | Custodiams |
> Accounting Firms | Law Firms | Billing
>
> The following is the encodeChildren() method of *HtmlNavigationBar*
>
>@Override
> public void encodeChildren(FacesContext context) throws IOException
> {
> ResponseWriter writer = context.getResponseWriter();
> List children = getChildren();
> int count = children.size();
>
> for (int i = 0; i < count; i++) {
> UIComponent child = children.get(i); // -- why does
> 'New link' appear at index == 0?
> if (child instanceof HtmlNavigationLink) {
> child.encodeAll(context);
> }
> }
> }
>
> As noted in the comment above, while the child component was added to the
> end of the list in the action method, it appears at index position 0 as the
> first child? Why is it so?
>
>
>
>
>

Re: Custom component with children - Child component added dynamically at end appears as first child when rendered

[Simon Lessard]

Hi,

Yes I was, and it does seem correctly done too... Who's in charge of calling
the formSubmitted method? Is is an action on a commandLink/Button?

On Tue, Oct 27, 2009 at 9:56 AM,  wrote:

>
> Hi Simon,
> Thanks for responding. I'm not quite sure what you mean by getter
> code for the navigation bar. Are you asking about the getter/setter for the
> navigation bar in my backing bean?
>
> *public* *class* TestBean {
>
> *private* HtmlNavigationBar navigationBar;
>
> *public* HtmlNavigationBar getNavigationBar() {
> *return* *null*;
> }
>
> *public* *void* setNavigationBar(HtmlNavigationBar navigationBar)
> {
> *this*.navigationBar = navigationBar;
> }
> }
>
> Thanks.
>
>
>  *Simon Lessard *
>
> 10/27/2009 07:13 PM
>  Please respond to
> "MyFaces Development" 
>
>   To
> MyFaces Development 
> cc
>   Subject
> Re: Custom component with children - Child component added
> dynamically at end appears as first child when rendered
>
>
>
>
> Hi Keerthi,
>
> Can you post your getter code for the navigation bar please? Make sure it
> simply return null. My hunch is that your backing bean acts also as the
> component factory (which can incredibly bad).
>
>
> p.s. This post belong to the user list. Dev lists on Apache are for those
> developing the product. You may be a developer, but from Apache MyFaces
> perspective, you're an user.
>
>
> Regards,
>
> ~ Simon
>
> On Tue, Oct 27, 2009 at 9:31 AM, 
> <*kpanneersel...@inautix.co.in*>
> wrote:
>
> I have a custom JSF component that renders navigation links. The following
> is a typical usage of the component:
>
>  actionListener="#{testBean.navigationLinkClicked}" immediate="true"
> binding="#{testBean.navigationBar}">
> 
>  active="true"/>
> 
>
> 
> 
>  clickable="false"/>
>  clickable="false"/>
> 
>
> And, the rendered content will appear as following:
>
> Primary Data | Principals | Administrators | Custodiams | Accounting Firms
> | Law Firms | Billing
>
>
> As you notice, the navigationBar component is bounded to
> #{testBean.navigationBar} which is defined as below in the Backing bean:
>
> public class TestBean {
>
> private HtmlNavigationBar navigationBar;
>  // -- getter & setter for navigationBar
>
> public String formSubmitted() {
> HtmlNavigationLink link = new HtmlNavigationLink();
> link.setId("link");
> link.setValue("New link");
>
> navigationBar.getChildren().add(link)
>
> return null;
> }
> }
>
>
> The backing bean has an action method formSubmitted() that adds a child
> (HtmlNavigationLink) component to the parent (HtmlNavigationBar)
> dynamically. This method is invoked on form submit. I thought that this
> newly added child would be the last child (as it was added to end of the
> children list). But, when the navigationBar renders its children, the
> HtmlNavigationLink 'New link' appears as the first child causing the content
> rendered as below:
>
>
> New Link | Primary Data | Principals | Administrators | Custodiams |
> Accounting Firms | Law Firms | Billing
>
> The following is the encodeChildren() method of *HtmlNavigationBar*
>
>@Override
> public void encodeChildren(FacesContext context) throws IOException
> {
> ResponseWriter writer = context.getResponseWriter();
> List children = getChildren();
> int count = children.size();
>
> for (int i = 0; i < count; i++) {
> UIComponent child = children.get(i); // -- why does
> 'New link' appear at index == 0?
> if (child instanceof HtmlNavigationLink) {
> child.encodeAll(context);
> }
> }
> }
>
> As noted in the comment above, while the child component was added to the
> end of the list in the action method, it appears at index position 0 as the
> first child? Why is it so?
>
>
>
>

Re: Custom component with children - Child component added dynamically at end appears as first child when rendered

[Simon Lessard]

Hi Keerthi,

Can you post your getter code for the navigation bar please? Make sure it
simply return null. My hunch is that your backing bean acts also as the
component factory (which can incredibly bad).


p.s. This post belong to the user list. Dev lists on Apache are for those
developing the product. You may be a developer, but from Apache MyFaces
perspective, you're an user.


Regards,

~ Simon

On Tue, Oct 27, 2009 at 9:31 AM,  wrote:

>
> I have a custom JSF component that renders navigation links. The following
> is a typical usage of the component:
>
>  actionListener="#{testBean.navigationLinkClicked}" immediate="true"
> binding="#{testBean.navigationBar}">
> 
>  active="true"/>
> 
> 
> 
>  clickable="false"/>
>  clickable="false"/>
> 
>
> And, the rendered content will appear as following:
>
> Primary Data | Principals | Administrators | Custodiams | Accounting Firms
> | Law Firms | Billing
>
>
> As you notice, the navigationBar component is bounded to
> #{testBean.navigationBar} which is defined as below in the Backing bean:
>
> public class TestBean {
>
> private HtmlNavigationBar navigationBar;
>  // -- getter & setter for navigationBar
>
> public String formSubmitted() {
> HtmlNavigationLink link = new HtmlNavigationLink();
> link.setId("link");
> link.setValue("New link");
>
> navigationBar.getChildren().add(link)
>
> return null;
> }
> }
>
>
> The backing bean has an action method formSubmitted() that adds a child
> (HtmlNavigationLink) component to the parent (HtmlNavigationBar)
> dynamically. This method is invoked on form submit. I thought that this
> newly added child would be the last child (as it was added to end of the
> children list). But, when the navigationBar renders its children, the
> HtmlNavigationLink 'New link' appears as the first child causing the content
> rendered as below:
>
>
> New Link | Primary Data | Principals | Administrators | Custodiams |
> Accounting Firms | Law Firms | Billing
>
> The following is the encodeChildren() method of *HtmlNavigationBar*
>
>@Override
> public void encodeChildren(FacesContext context) throws IOException
> {
> ResponseWriter writer = context.getResponseWriter();
> List children = getChildren();
> int count = children.size();
>
> for (int i = 0; i < count; i++) {
> UIComponent child = children.get(i); // -- why does
> 'New link' appear at index == 0?
> if (child instanceof HtmlNavigationLink) {
> child.encodeAll(context);
> }
> }
> }
>
> As noted in the comment above, while the child component was added to the
> end of the list in the action method, it appears at index position 0 as the
> first child? Why is it so?
>
> 
> Keerthi Panneerselvam
> Development Delivery - NetxOffice
> iNautix Technologies India Private Limited, an affiliate of Pershing LLC, a
> subsidiary of The Bank of New York Mellon Corporation
> www.inautix.co.in
> Office: 612-6696 (V)
> Email: kpanneersel...@inautix.co.in

Re: [Trinidad] [API] Making XhtmlConstants (from IMPL module) a public API

[Simon Lessard]

Hi all,

Personally, I would prefer to see that class divided in more specialized
classes like :

XhtmlElements
{
public static final String DIV = "div"; (or could be DIVISION)
public static final String TABLE = "table";
public static final String TABLE_BODY = "tbody";
 public static final String TABLE_DATA_CELL = "td";
 public static final String TABLE_HEADER_CELL = "th";
public static final String TABLE_ROW = "tr";
// ...
}

XhtmlAttributes
{
public static final String HANDLER_CLICK = "onclick";
public static final String STYLE_CLASS = "class";
// ...
}

And so on. This kind of separation often make the constant names clearer (no
need to prefix the constant type like ELEMENT_ or ATTR_).

About the general idea to move such constants to the API, I'm +1 though.


Regards,

~ Simon

On Mon, Oct 19, 2009 at 8:35 AM, Scott O'Bryan  wrote:

> Why is this being done again?
>
> Sent from my iPhone
>
>
> On Oct 18, 2009, at 10:32 PM, Blake Sullivan 
> wrote:
>
>  +1
>>
>> -- Blake Sullivan
>>
>> On Oct 18, 2009, at 9:11 PM, Matthias Wessendorf wrote:
>>
>>  Maybe we should also rename the "old" XhtmlConstants class ?
>>> Would make sense, as all the (x)html stuff is about to be moved to API.
>>>
>>> Since this class is containing misc things, like HTML (gone), events,
>>> params
>>> and other rendering stuff (e.g. the * for the inputText
>>> (secret:true)), we could
>>> be lazy by renaming it to something like:
>>>
>>> TrinidadRenderingConstants
>>>
>>> We could also try to clean it up even more, by making it multiple
>>> classes...
>>> From looking at the comments it looks like it has been copied from
>>> multiple
>>> places to a single class; So not sure if we really wanna go to split it
>>> up even
>>> more...
>>>
>>> -Matthias
>>>
>>> On Fri, Oct 16, 2009 at 11:21 AM, Blake Sullivan
>>>  wrote:
>>>
 +1

 -- Blake Sullivan

 Matthias Wessendorf said the following On 10/16/2009 11:12 AM PT:

 On Thu, Oct 15, 2009 at 6:12 PM, Blake Sullivan
  wrote:


 Matthias Wessendorf said the following On 10/15/2009 5:48 PM PT:


 Hi,

 I'd like to move the XhtmlConstants class to the API.
 The only dependency on another IMPL class is very simple.
 It is a constant, that resolves to a String ("portlet").

 If nobody disagrees, I will move on with the move.
 Yeah, just on trunk (Trinidad 1.2.x)

 Thx,
 Matthias




 Matthias,

 A bunch of the constants appear to be implementation-dependent.  Rather
 than
 making the entire class public, I think you should come up with a
 proposal
 for which constants you want to move to a public class.


 took a more detailed look and noticed that a bunch of mixed things are
 in that class.

 I think we should maybe just move the XHTML specific stuff to be an
 API part, b/c
 some of the stuff *can* be useful one other (renderer) implementations
 as
 well.

 Here is a list, of what I have in mind:
 public static final String FACET_PORTLET = "portlet";
 public static final String SCRIPT_NAME = "script";
 public static final String H_ALIGN_END = "end";
 public static final String V_ALIGN_MIDDLE = "middle";
 public static final String V_ALIGN_TOP = "top";
 public static final String DIV_ELEMENT  = "div";
 public static final List HEADER_ELEMENTS =
  Arrays.asList(new String[]{"h1", "h2", "h3",
 "h4", "h5", "h6"});
 public static final String LINK_ELEMENT = "a";
 public static final String PARAGRAPH_ELEMENT = "p";
 public static final String SCRIPT_ELEMENT   = "script";
 public static final String SPAN_ELEMENT = "span";
 public static final String TABLE_DATA_ELEMENT   = "td";
 public static final String TABLE_BODY_ELEMENT   = "tbody";
 public static final String TABLE_ELEMENT= "table";
 public static final String TABLE_HEADER_ELEMENT = "th";
 public static final String TABLE_ROW_ELEMENT= "tr";

 public static final String FIELDSET_ELEMENT = "fieldset";
 public static final String LEGEND_ELEMENT   = "legend";
 public static final char NBSP_CHAR = 0xA0;
 public static final String NBSP_STRING = String.valueOf(NBSP_CHAR);

 public static final String ALIGN_ATTRIBUTE  = "align";
 public static final String COLS_ATTRIBUTE   = "cols";
 public static final String COLSPAN_ATTRIBUTE= "colspan";
 public static final String HEIGHT_ATTRIBUTE = "height";
 public static final String HREF_ATTRIBUTE   = "href";
 public static final String ID_ATTRIBUTE = "id";
 public static final String NOWRAP_ATTRIBUTE = "nowrap";
 public static final String ONCLICK_ATTRIBUTE= "onclick";
 public static final String ROWS_ATTRIBUTE  = "rows";
 public stat

Re: VOTE: jsf 2.0: should cyclic references in managed-bean custom scopes be detected?

[Simon Lessard]

+1 for the project stage idea.

On Tue, Oct 13, 2009 at 10:28 AM, Michael Concini wrote:

> What about using project stage to determine which behavior to follow?  If
> we're in production stage we don't check for best performance, but in
> development/test stages we perform the check.
> Alternatively, could we at least make it configurable through an
> org.apache.myfaces param in web.xml so apps that have been fully tested can
> disable the check?
>
> Thanks,
> Mike
>
>
> Jakob Korherr wrote:
>
>> Hi everbody.
>>
>> While working on MYFACES-2375, I got stuck at the following scenario:
>>
>> Managed bean m1 has a custom scope #{m2.scope} and managed bean m2 has a
>> custom scope #{m1.scope}.
>> In this scenario you will get a StackOverflowException when trying to
>> create one of the two managed beans.
>>
>> RI really ends in a StackOverflowException, should MyFaces end in such a
>> Exception too or detect the cyclic reference and throw an ELException?
>>
>> Mike Kienenberger told me the following: "We have a precedent set on
>> making MyFaces proactive on detecting error conditions in the
>> configuration."
>>
>> The only problem is, that checking the cyclic references would not happen
>> once at MyFaces startup, but every time a managed bean will be created,
>> which means it slows down the application.
>>
>> What is your opinion on this question?
>> Vote +1, if you think MyFaces should detect cyclic references in the
>> managed bean scope.
>>
>
>

Re: [VOTE] use of jul or commons logging on myfaces core 2.0

[Simon Lessard]

+1 for jul. However, I think we should add an utility class
(ServletContextListnener? This is the easiest way I know of, if it qualifies
for easiest at all) in myfaces-shared or extension to make it easier to
configure the logger because it's way more annoying to configure than
commons-logging backed with log4j imho.


Regards,

~ Simon

On Thu, Oct 1, 2009 at 1:25 AM, Mario Ivankovits  wrote:

>  +1 for jul
>
>
>
> reduces dependencies - and sun also use it, no?
>
>
>
>
>
> *Von:* Leonardo Uribe [mailto:lu4...@gmail.com]
> *Gesendet:* Donnerstag, 01. Oktober 2009 04:06
> *An:* MyFaces Development
> *Betreff:* [VOTE] use of jul or commons logging on myfaces core 2.0
>
>
>
> Hi
>
> Right now, facelets code added to myfaces core 2.0.x branch uses jul in
> this form:
>
> protected final static Logger log =
> Logger.getLogger("facelets.viewhandler");
>
> But the original myfaces code uses commons logging, (so if there is no
> agreement about use jul, we should unify logging code using
> commons-logging).
>
> It is necessary to unify in one way or another the code of 2.0.x branch,
> but before that, it is necessary to ask the community about this issue.
>
> So, please vote in this way:
>
> +1 for jul
> +1 for commons-logging
> +0
> -1 and let the code as is (and a reason why).
>
> regards,
>
> Leonardo Uribe
>

Re: [Proposal] New MyFaces Commons module - Agent Detection

[Simon Lessard]

Hi,

I wouldn't mind seeing that part shared.

~ Simon

On Tue, Sep 22, 2009 at 5:30 PM, Udo Schnurpfeil  wrote:

> Hi Marius,
>
> it sounds very nice for me. Can I take a look to the implementation
> anywhere? I would like to check if it fits to Tobago.
>
> So we can share the code instead of reimplementing the same stuff twice or
> more.
>
> Regards,
>
> Udo
>
>
> Marius Petoi schrieb:
>
>  Hi everybody,
>>
>> I would like to propose the creation of a new module in MyFaces Commons,
>> that will handle agent detection, a feature which I hope you will consider,
>> as such a module would be useful to any component set out there (or at least
>> to the ones in MyFaces).
>>
>> My work is based on what already exists in Trinidad: basically I extracted
>> the code from there and packaged it as a module that integrates with the
>> MyFaces Commons build; the functionality is the same, I just refactored and
>> cleaned up a bit the code (the main change is that I extracted the constants
>> from the interfaces into separate classes). I removed from this basic module
>> the additional capabilities support, which Trinidad has, as, in my opinion,
>> this is something specific for Trinidad (at least in this initial version).
>>
>> Also, I adapted Trinidad to work with this new module, I have patches with
>> all the modifications, in case you guys decide to use the new module in
>> Trinidad also (the current Trinidad functionality doesn't change).
>>
>> Would the community be interested in having this?
>>
>> Regards,
>> Marius
>>
>

Re: [Skinning] State of independent skinning myfaces subproject?

[Simon Lessard]

Hi,

The last messages that were exchanged on that subject were still on the
requirement list, see http://markmail.org/message/ixfdm4ajl7f6zbxl. We were
not so much agreeing and there was still the portlet issue to resolve. It's
an important issue, and would be a great addition, reviving the thread could
be a good idea.


Regards,

~ Simon


On Tue, Sep 22, 2009 at 9:47 AM, Marius Petoi wrote:

> Hello everybody,
>
> You started discussing about making an independent module for skinning,
> starting from the skinning in Trinidad (
> http://markmail.org/thread/qlmp2w7j6clccd5r). I have some time allocated
> to work on this subject...and I would like to know what the status of the
> project is.
>
> Regards,
> Marius
>

Re: JSF2 facelet question (Simon Lessard?)

[Simon Lessard]

Hi Werner,

I'll reread the spec about your example, I think it should be on both
component, but I'll try to make sure of it. Also, I'm not against putting
the support for that functionality in the impl, but I'm not too warm about
it either, since custom component developers won't be able to leverage it
without linking themselves to MyFaces impl. For that part I'll also drill
down the spec to see if there's any indication about that use case, but I
think we might have to ping the EG.


Regards,

~ Simon

On Wed, Sep 2, 2009 at 4:29 AM, Werner Punz  wrote:

> Ok never mind I think I found the info in 3.6.2.1 Composite Component
> Metadata of the spec
>
> I will work my way in from there.
> Btw. one thing I am noticed for now is that there is no direct way to push
> in behaviors in child tag handlers. Especially since you do not know the
> nesting depth of the next behavior aware component.
> And since the meta data api is only available for composite components for
> now we cannot work with it on that case.
>
> We probably have to extend either our ComponentTagHandler class or our
> ComponentTagHandlerDelegate class to look for possible behaviors integrated
> into the components newly generated.
>
> Here is a small case
>
> 
>
>
> 
> Should attach the behavior to both components
>
> now public void apply(FaceletContext faceletContext, UIComponent parent)
> is responsible for creating the component.
> As it is done only the current component is created which means
> at the time the f:ajax tag is hit none of the two command buttons are
> created.
>
> all you can do is to store a list of behaviors and then find a way to
> attach the behaviors via some outside functionality.
>
> As I could see the extension point of all this probably would be
> the ComponentTagHandlerFactory, but since we are in our own system
> would it be possible maybe to extend our componenttaghandler impl class
> with some functionality? I am not so eager to program this into an extension
> point which might be overwritten by a user setting.
>
> The idea would be to add a thread local to an impl class of the
> ComponentTagHandler which would get the additional behavior data.
> Which then the component tag handler, in case of being a behavior holder
> could attach to the component.
>
> (Probably the onComponentCreated callback from the ComponentTagHandler
> would be the ideal place to place the code)
>
>
> This also would mean whatever generates the ComponentTagHandler probably
> has to generate an impl class.
>
> (Probably one of the core Facelet classes)
> The other way would be the extension point over the delegate factory as I
> said, there we could work in a similar way.
>
>
>
>
> Werner
>
>
>
>
>
> Werner Punz schrieb:
>
>  as it seems I have now the tag handler for the jsf:ajax tag on my back, my
>> main gripe are some details regarding the tag handler.
>>
>> I mostly figured out most steps except one thing.
>>
>> What I need is following
>>
>> I have my tag handler being embedded in a composite component
>>
>> 
>>
>> 
>>
>> The main issue here is that if I use the ajax tag I have to attach it to
>> an event in most cases it is onclick
>> which means if the composite has onClick defined I have to get a way
>> to get references to the embedded components which reference onClick event
>> handler defined in the composite interface.
>> Once I have references to the component or their respective tag handlers I
>> am set, then I can work my way in and attach the behavior as expected.
>>
>>
>> Can anyone point me towards a way to get there?
>>
>>
>> Werner
>>
>>
>>
>

Re: [VOTE] Extensions - Scripting subproject

[Simon Lessard]

+1

On Fri, Aug 14, 2009 at 7:09 AM, Leonardo Uribe  wrote:

> +1
>
> 2009/8/14 Jan-Kees van Andel 
>
> +1
>>
>> 2009/8/14 Bruno Aranda :
>> > +1
>> >
>> > 2009/8/14 Matthias Wessendorf :
>> >> +1 :-)
>> >>
>> >> On Fri, Aug 14, 2009 at 11:24 AM, Werner Punz
>> wrote:
>> >>> Hello everyone just to make sure things are formal enough I am going
>> to open
>> >>> a vote on this
>> >>>
>> >>> I want to open a myfaces-scripting extensions subproject/module within
>> the
>> >>> domain of our extensions project. (For now we have projects not
>> modules)
>> >>> The current status is that this project will add a scripting extension
>> to
>> >>> myfaces which allows to code JSF artefacts in groovy and enables
>> dynamic
>> >>> reloading without server shutdown of those artefacts.
>> >>>
>> >>> The plan for now is, to commit the initial code which works for
>> myfaces 1.2
>> >>> and then work on resolving pending issues regarding the myfaces
>> connectivity
>> >>> and generally the server connectivty and then
>> >>> move the code over to MyFaces 2.0.
>> >>>
>> >>> 
>> >>> [ ] +1 for opening the project for the initial commit and the ongoing
>> work
>> >>> [ ] +0
>> >>> [ ] -1 for not opening it
>> >>> 
>> >>>
>> >>> Werner
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Matthias Wessendorf
>> >>
>> >> blog: http://matthiaswessendorf.wordpress.com/
>> >> sessions: http://www.slideshare.net/mwessendorf
>> >> twitter: http://twitter.com/mwessendorf
>> >>
>> >
>>
>
>

Re: Problem when rerendering with validation errors

[Simon Lessard]

Hi,

Since it's an internal API I think we should just flush the class down the
drain.


~ Simon

On Mon, Aug 10, 2009 at 12:47 PM, Jan-Kees van Andel <
jankeesvanan...@gmail.com> wrote:

> Removing the  element from my faces-config.xml did the
> trick.
>
> Funny that everything worked properly, except the rerendering. Should
> we add some code to prevent people from making the same mistake?
>
> Thanks Mike,
> JK
>
>
> 2009/8/10 Michael Concini :
> > Jan-Kees van Andel wrote:
> >>>
> >>> The default in the current 2.0 runtime should be using
> >>> org.apache.mfyaces.application.ViewHandlerImpl, which is a single class
> >>> implementation for both JSP and facelets.  It uses the FactoryFinder to
> >>> get
> >>> the right ViewDeclarationLanguage implementation depending on whether
> >>> you're
> >>> using JSP or facelets since nearly all of the actual work is done in
> the
> >>> VDL
> >>> classes now.  The old JSP and facelets ViewHandler impls shouldn't
> really
> >>> be
> >>> used anymore and as far as I know haven't been updated to the 2.0 spec.
> >>>
> >>
> >> I'm gonna check it tonight (@work now), but the last time I checked, I
> >> saw the ViewHandlerImpl being returned, but I have to check to be
> >> sure.
> >>
> >> But you're saying that specifying the  element in
> >> faces-config.xml is redundant and probably incorect? In that case, I'm
> >> gonna remove it and check if it works. I've added it a while ago
> >> because I got the JSP ViewHandler back then. Maybe things have changed
> >> in the meantime.
> >>
> >>
> >
> > That makes sense if you had originally set things up more than a few
> weeks
> > ago.  The new ViewHandlerImpl class was in place but we hadn't changed
> the
> > default config to use it until sometime in July once most of the VDL
> impls
> > were ready and we were trying to get some apps working.
> >>>
> >>> If you're getting the JSP VDL back from ViewHandlerImpl, then there is
> >>> something not configured right either.  Maybe in our default config
> files
> >>> or
> >>> the factory definition?
> >>> Let me know if you need me to check into it and I should be able to
> later
> >>> this week.  I'm on vacation visiting family right now though so it
> might
> >>> be
> >>> a few days.
> >>>
> >>
> >> Thanks for the offer. I'm gonna debug a bit first, and then I'll come
> >> back to you.
> >>
> >> Regards,
> >> Jan-Kees
> >>
> >>
> >
> > Sounds good...shoot an email to let me know if you need me to check on
> it.
> > Thanks,
> > Mike
> >
>

Re: FYI - Fw: [webbeans-dev] How does JSF deal with managed beans when Web Beans/299 is present?

[Simon Lessard]

Ah, the incredibly messy JSR-299 issue... About everything about it is done
badly. JSF 2.0 is going to depend on it to support some of the annotation
and conversation scope. While JSR-299 activates conversation only when JSF
is present, lovely circular dependency isn't it? Most of the times I close
my eyes and try to convince myself that JSR-299 does not exist or was done
correctly earlier in Java life so that the various dependencies and
separation of concerns could be correct. Like conversation scope should have
been a custom scope implemented by JSF, this would have resulted in 2
advantages, correct dependency structure, and out-of-the-box conversation
support in JSF.

Anyway, a parameter switch sounds like a good idea.

~ Simon

On Wed, Aug 5, 2009 at 5:18 AM, Matthias Wessendorf wrote:

> my friend Mark Struberg pointed me to this interesting thread:
> => http://markmail.org/thread/ml6l26r7twgab53c
>
>
> -Matthias
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: Issues with the Facelets implementation

[Simon Lessard]

Hmm,

I used the latest nightly build when I integrated the code. However, that
was about 3~4 months ago, so maybe it changed a little since then, or there
was another usable branch that I was unaware of. That being said, maybe we
should add the required changes by ourselves. Even if Facelets is ASL 2.0, I
think it would be healthy to have 2 different implementation in case one
produces an innovation that could improve performance or another aspect of
it.

On Wed, Aug 5, 2009 at 9:03 AM, Curtiss Howard wrote:

> Hi,
>
> I just wanted to let everyone know that with a couple tweaks to the
> Facelets implementation I've been able to get the Mojarra "Guess
> Number 2.0" custom taglib working, which does some client-side JS
> validation.  It looks like the 2.0 codepath is looking very good so
> far!
>
> However, in the process I've noticed that the Facelets implementation
> we're using is a bit... out of date, at least with respect to the
> Facelets taglib parser.  It seems to be geared towards version 1.0
> documents, and the demo app I'm working with ships a 2.0 version
> document.  Due to the parser only understanding 1.0 documents, it
> turns on DTD validation and turns off namespace handling.  The
> problem, of course, with recent versions of the Facelets taglib
> document is that it does schema validation and is namespace-aware.
>
> So what's the deal with the Facelets implementation we're using?  I'm
> guessing it's out of date, or at least portions of it are.  Is it
> going to be upgraded or should I try to make the taglib parser do a
> dual-parsing approach?  If so, I've got a few more questions :).  Let
> me know what you guys think.
>
> Thanks,
>
>
> Curtiss Howard
>

Re: javax.faces.bean? (Attn: Jan Kees)

[Simon Lessard]

Yup,

The actual text from the all classe description (the page no one ever read
like the package description one) is:

'*These javadoc files constitute the “Faces Managed Bean Annotation
Specification for Containers Conforming to Servlet 2.5 and Beyond”*

*At the time of this writing, a forthcoming JCP effort is being planned to
extract the specification for managed beans from JSF and place it into its
own specification. To account for this effort and to avoid introducing
classes into JSF 2.0 that would have to be deprecated when this effort is
complete, implementations of JSF 2.0 are not required to implement the
“Faces Managed Bean Annotation Specification for Containers Conforming to
Servlet 2.5”. However, JSF implementations are strongly encouraged to
implement this specification, as it provides significant improvements in
ease of use.*

*The annotations must be processed as specified in section JSF.11.5.1.'*

On Mon, Aug 3, 2009 at 10:57 AM, Jan-Kees van Andel <
jankeesvanan...@gmail.com> wrote:

> Aha, was that the reason? I know the first commit was in "model", but
> I saw some time ago they were moved to "bean".
>
> The bean package sounds better to me anyway. Model contains the
> DataModels...
>
> /JK
>
> 2009/8/3 Simon Lessard :
> > Hi,
> >
> > They used to be under javax.faces.model. However, due to overlap with
> > JSR-299 they were moved to javax.faces.bean, see the companion JavaDoc
> > (under \managed-bean-javadocs).
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On Mon, Aug 3, 2009 at 10:12 AM, Curtiss Howard <
> curtiss.how...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> The JSF 2.0 sample I'm trying to get working annotates its bean with
> >> @javax.faces.bean.ManagedBean, among other things.  I noticed that JK
> >> dropped in annotations for javax.faces.bean, but I'm wondering where
> >> these annotations are defined.  They certainly aren't listed in the
> >> "final" Javadocs dated 6/26, so what gives?  I pulled this sample from
> >> Mojarra's official RI binary zip, so I assume that this wasn't an
> >> accident, but I'm baffled as to why I can't find documentation on
> >> them.
> >>
> >> Can anyone shed some light on this situation?
> >>
> >> Thanks,
> >>
> >>
> >> Curtiss Howard
> >
> >
>

Re: javax.faces.bean? (Attn: Jan Kees)

[Simon Lessard]

Hi,

They used to be under javax.faces.model. However, due to overlap with
JSR-299 they were moved to javax.faces.bean, see the companion JavaDoc
(under \managed-bean-javadocs).


Regards,

~ Simon

On Mon, Aug 3, 2009 at 10:12 AM, Curtiss Howard wrote:

> Hi,
>
> The JSF 2.0 sample I'm trying to get working annotates its bean with
> @javax.faces.bean.ManagedBean, among other things.  I noticed that JK
> dropped in annotations for javax.faces.bean, but I'm wondering where
> these annotations are defined.  They certainly aren't listed in the
> "final" Javadocs dated 6/26, so what gives?  I pulled this sample from
> Mojarra's official RI binary zip, so I assume that this wasn't an
> accident, but I'm baffled as to why I can't find documentation on
> them.
>
> Can anyone shed some light on this situation?
>
> Thanks,
>
>
> Curtiss Howard
>

Re: [myfaces][jsf 2.0] Status of facelets integration

[Simon Lessard]

Hi,

Ok it's commited. I tried to add some comments to the code prior to the
commit. Mostly, what need to be done is the implementation of :

FaceletViewDeclarationLanguage
- getComponentMetadata
- getScriptComponentResource
- getStateManagementStrategy
- renderView also need to be revisited most likely

Various tag handlers requires to be plugged with the delegate pattern (am I
the only one finding that part not incredibly clear?). Anyway, I'll try to
read more on those and at worst check Mojarra a bit and try to contribute on
that.

Theoretically, the Facelet compiler should work with the current code, but I
didn't try it.


Regards,

~ Simon

On Tue, Jul 28, 2009 at 12:05 PM, Michael Concini wrote:

> Great news.  Thanks a lot.
>
> Simon Lessard wrote:
>
>> Hi,
>>
>> I'll try to commit that tonight.
>>
>> ~ Simon
>>
>> On Tue, Jul 28, 2009 at 10:20 AM, Michael Concini > mconc...@gmail.com>> wrote:
>>
>>Hi Simon,
>>
>>I wanted to do a quick follow up here.  There are a few of us who
>>are ready to start filling in the gaps once the initial commit is
>>done.  Have you had a chance to look into committing what you have
>>so far yet?  Any ETA on when you might be able to do that so we
>>can get started?
>>
>>Thanks,
>>Mike
>>
>>
>>Matthias Wessendorf wrote:
>>
>>hey simon,
>>
>>is it possible to commit your current stuff ? Once it is kinda
>>visible,
>>others could provide the missing bits.
>>
>>-Matthias
>>
>>On Wed, Jul 22, 2009 at 1:42 PM, Simon
>>Lessardmailto:simon_less...@dmr.ca>> wrote:
>>
>>Hi,
>>
>>I'm trying to work on it, but frankly I'm overloaded
>>beyond what I was
>>expecting so I could use help quite badly. Theoretically,
>>three parts
>>remains to the integration:
>>
>>1. Link the Facelets code with the Delegate pattern on API
>>side;
>>2. Finish the Facelet VDL (Facelets compiler integration)
>>3. Adjust some classes (should be minor, mainly regarding
>>delegates that
>>could have been handled in 1)
>>
>>
>>Regards,
>>
>>~ Simon
>>
>>On Wed, Jul 22, 2009 at 3:46 AM, Matthias Wessendorf
>>mailto:mat...@apache.org>>
>>wrote:
>>
>>On Wed, Jul 22, 2009 at 8:27 AM, Leonardo
>>Uribemailto:lu4...@gmail.com>> wrote:
>>
>>Hi
>>
>>Just a small question: What is the status of
>>facelets integration?.
>>After
>>review the work done at this time in myfaces core
>>2.0.x, facelets
>>integration code are becoming most critical. The
>>remaining points listed
>>below:
>>
>> - Facelets PDL
>> - Client behavior API (depends from facelets and
>>composite component
>>stuff)
>> - Error handling API (and run through existing
>>classes to make sure the
>>new
>>exception specification is enforced)
>> - Partial view API
>> - Partial State Saving (pending integration with
>>facelets)
>> - New tags (mostly linked to Facelets)
>>
>>depends in one way or another with facelets. It is
>>safe to work on it or
>>there is some unknown code to be committed? I want
>>to contribute in this
>>
>>I think Simon has some facelets-related code.
>>
>>
>>area but it could be good to know which parts
>>needs help and what things
>>are
>>done to prevent duplicate work.
>>
>>regards
>>
>>Leonardo Uribe
>>
>>
>>
>>--
>>Matthias Wessendorf
>>
>>blog: http://matthiaswessendorf.wordpress.com/
>>sessions: http://www.slideshare.net/mwessendorf
>>twitter: http://twitter.com/mwessendorf
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

Re: [myfaces][jsf 2.0] Status of facelets integration

[Simon Lessard]

Hi,

I'll try to commit that tonight.

~ Simon

On Tue, Jul 28, 2009 at 10:20 AM, Michael Concini wrote:

> Hi Simon,
>
> I wanted to do a quick follow up here.  There are a few of us who are ready
> to start filling in the gaps once the initial commit is done.  Have you had
> a chance to look into committing what you have so far yet?  Any ETA on when
> you might be able to do that so we can get started?
>
> Thanks,
> Mike
>
>
> Matthias Wessendorf wrote:
>
>> hey simon,
>>
>> is it possible to commit your current stuff ? Once it is kinda visible,
>> others could provide the missing bits.
>>
>> -Matthias
>>
>> On Wed, Jul 22, 2009 at 1:42 PM, Simon Lessard
>> wrote:
>>
>>
>>> Hi,
>>>
>>> I'm trying to work on it, but frankly I'm overloaded beyond what I was
>>> expecting so I could use help quite badly. Theoretically, three parts
>>> remains to the integration:
>>>
>>> 1. Link the Facelets code with the Delegate pattern on API side;
>>> 2. Finish the Facelet VDL (Facelets compiler integration)
>>> 3. Adjust some classes (should be minor, mainly regarding delegates that
>>> could have been handled in 1)
>>>
>>>
>>> Regards,
>>>
>>> ~ Simon
>>>
>>> On Wed, Jul 22, 2009 at 3:46 AM, Matthias Wessendorf 
>>> wrote:
>>>
>>>
>>>> On Wed, Jul 22, 2009 at 8:27 AM, Leonardo Uribe
>>>> wrote:
>>>>
>>>>
>>>>> Hi
>>>>>
>>>>> Just a small question: What is the status of facelets integration?.
>>>>> After
>>>>> review the work done at this time in myfaces core 2.0.x, facelets
>>>>> integration code are becoming most critical. The remaining points
>>>>> listed
>>>>> below:
>>>>>
>>>>>  - Facelets PDL
>>>>>  - Client behavior API (depends from facelets and composite component
>>>>> stuff)
>>>>>  - Error handling API (and run through existing classes to make sure
>>>>> the
>>>>> new
>>>>> exception specification is enforced)
>>>>>  - Partial view API
>>>>>  - Partial State Saving (pending integration with facelets)
>>>>>  - New tags (mostly linked to Facelets)
>>>>>
>>>>> depends in one way or another with facelets. It is safe to work on it
>>>>> or
>>>>> there is some unknown code to be committed? I want to contribute in
>>>>> this
>>>>>
>>>>>
>>>> I think Simon has some facelets-related code.
>>>>
>>>>
>>>>
>>>>> area but it could be good to know which parts needs help and what
>>>>> things
>>>>> are
>>>>> done to prevent duplicate work.
>>>>>
>>>>> regards
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>

Re: [myfaces][jsf 2.0] Status of facelets integration

[Simon Lessard]

Hi,

I'm trying to work on it, but frankly I'm overloaded beyond what I was
expecting so I could use help quite badly. Theoretically, three parts
remains to the integration:

1. Link the Facelets code with the Delegate pattern on API side;
2. Finish the Facelet VDL (Facelets compiler integration)
3. Adjust some classes (should be minor, mainly regarding delegates that
could have been handled in 1)


Regards,

~ Simon

On Wed, Jul 22, 2009 at 3:46 AM, Matthias Wessendorf wrote:

> On Wed, Jul 22, 2009 at 8:27 AM, Leonardo Uribe wrote:
> > Hi
> >
> > Just a small question: What is the status of facelets integration?. After
> > review the work done at this time in myfaces core 2.0.x, facelets
> > integration code are becoming most critical. The remaining points listed
> > below:
> >
> >  - Facelets PDL
> >  - Client behavior API (depends from facelets and composite component
> stuff)
> >  - Error handling API (and run through existing classes to make sure the
> new
> > exception specification is enforced)
> >  - Partial view API
> >  - Partial State Saving (pending integration with facelets)
> >  - New tags (mostly linked to Facelets)
> >
> > depends in one way or another with facelets. It is safe to work on it or
> > there is some unknown code to be committed? I want to contribute in this
>
> I think Simon has some facelets-related code.
>
> > area but it could be good to know which parts needs help and what things
> are
> > done to prevent duplicate work.
> >
> > regards
> >
> > Leonardo Uribe
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: [JSF 2.0] which shared source branch for 2.0

[Simon Lessard]

Hi Michael,

Personally I think it should be a different branch, I just never created it
because I'm not familiar enough with it. This will also allow addition of
1.5 features in it so I'm all for it.


Regards,

~ Simon

On Mon, Jul 6, 2009 at 2:25 PM, Michael Concini  wrote:

> What branch of shared should we be using for JSF 2.0 specific changes?
>  Looking at the pom for impl, it looks like right now both 1.2.x and 2.0
> builds are using the shared 3.0.6 branch.
> I have some changes that will be ready to check in this week that following
> the current implementation should be in the shared sources.  Specifically
> I'm referring to the RendererBase classes and ELTagBase classes for the new
> OutcomeTarget components (h:link and h:button).
> If we wanted to maintain the same shared source level for both 1.2 and 2.0,
> I guess I could just put the base classes in the impl somewhere instead, but
> that doesn't seem ideal since it wouldn't follow the same pattern as every
> other component.
>
> Any advice/instruction here would be appreciated.
> Thanks,
> Mike
>
>
>

Re: Question about Facelets dev

[Simon Lessard]

Hi Curtiss,

Yes and no. Facelets is now ASL2 licensed so we're not reinventing the
wheel, we use the original code, modified only to include Java 5 features
(generics), repackage the classes and integrate the PDL semantics. However,
if I have time, I want to do some performance tests with current code. More
specifically, many handlers use a sorted array structure for attribute,
therefore the loopup takes O(log n) while the original sort itself uses
Collections.sort(), therefore a merge sort with O(n log n) complexity.
Although this is memory footprint optimal, I'm pretty sure a HashMap
construct would be fater, albeit a bit heavier on memory, so I'd like to do
some testing to see how much faster/heavier a Map would be.


Regards,

~ Simon

On Mon, Jun 29, 2009 at 11:26 AM, Curtiss Howard
wrote:

> On Mon, Jun 29, 2009 at 10:14 AM, Simon
> Lessard wrote:
> > Hi,
> >
> > I'm working on it. Hopefully it'll be done by next Sunday. So far I think
> I
> > should be able to handle it on my own. If not ready by Sunday, then I
> guess
> > some help would be needed. As for the taglib, we keep the tags defined by
> > the spec.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On Mon, Jun 29, 2009 at 8:54 AM, Curtiss Howard <
> curtiss.how...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> Just curious, what is the status of the Facelets dev work that is
> >> happening for MyFaces?  Just wondering if there is any help needed
> >> and/or what the ETA is.  Also, is that anticipated to include all of
> >> the taglib as well?
> >>
> >> Thanks,
> >>
> >>
> >> Curtiss Howard
> >
> >
>
> Simon,
>
> Thanks for the update.  WRT the taglib, what I meant was, does your
> work include implementing the tags as well?
>
> Thanks,
>
>
> Curtiss Howard
>

Re: Question about Facelets dev

[Simon Lessard]

Hi,

I'm working on it. Hopefully it'll be done by next Sunday. So far I think I
should be able to handle it on my own. If not ready by Sunday, then I guess
some help would be needed. As for the taglib, we keep the tags defined by
the spec.


Regards,

~ Simon

On Mon, Jun 29, 2009 at 8:54 AM, Curtiss Howard wrote:

> Hi,
>
> Just curious, what is the status of the Facelets dev work that is
> happening for MyFaces?  Just wondering if there is any help needed
> and/or what the ETA is.  Also, is that anticipated to include all of
> the taglib as well?
>
> Thanks,
>
>
> Curtiss Howard
>

Re: Status of unit test framework

[Simon Lessard]

Hi Matthias,

If we use myfaces-test we'll have the exact same issues as with shale-test
artifacts. That is, myfaces-test-2.0 will depend on myfaces-api-2.0 whereas
myfaces-api-2.0 requires myfaces-test to be tested and released. However,
Maven provide another, yet less known, feature that allow you to release the
tests of your artifact into a repository as well. Under such structure we
could have myfaces-api developped along with its tests (in the test
subfolder) and have another external project use those tests as a dependency
using:


org.apache.myfaces.core
myfaces-api
2.0.0-SNAPSHOT
test-jar
test


The above refer to the deployed test part of the artifact rather than the
project itself. That would be a way to release a MyFaces test framework ever
running into the interdependency issues again.


Regards,

~ Simon

On Tue, Jun 16, 2009 at 11:53 AM, Matthias Wessendorf wrote:

> On Tue, Jun 16, 2009 at 8:30 AM, Simon Lessard
> wrote:
> > Hi,
> >
> > I think the Shale-test drop has been made, but we still need to integrate
> it
> > with the codebase. We'll also have to determine how to distribute it. I
>
> correct, I ran into some maven issue here, and stop there.
> feel free to continue.
>
> > would see it as myfaces-api artifact-id, but using test-jar packaging as
> I
>
> instead of myfaces-test ?
>
> > think it's the only safe way to handle the bidirectional dependency in
> this
> > case. I don't know is Apache usually release and deploy their test-jar
> > though, so it's still a peding issue I think.
> >
> >
> > ~ Simon
> >
> > On Tue, Jun 16, 2009 at 11:28 AM, Curtiss Howard <
> curtiss.how...@gmail.com>
> > wrote:
> >>
> >> On Tue, Jun 16, 2009 at 10:45 AM, Leonardo Uribe
> wrote:
> >> > Hi
> >> >
> >> > If you are taking about the tests that does not allowed compile
> tomahawk
> >> > in
> >> > offline mode, it was fixed yesterday.
> >> >
> >> > regards
> >> >
> >> > Leonardo Uribe
> >> >
> >>
> >> No, I was thinking more about how the 2.0 impl tests don't work :).
> >>
> >>
> >> Curtiss Howard
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: Status of unit test framework

[Simon Lessard]

Hi,

I think the Shale-test drop has been made, but we still need to integrate it
with the codebase. We'll also have to determine how to distribute it. I
would see it as myfaces-api artifact-id, but using test-jar packaging as I
think it's the only safe way to handle the bidirectional dependency in this
case. I don't know is Apache usually release and deploy their test-jar
though, so it's still a pending issue I think.


~ Simon

On Tue, Jun 16, 2009 at 11:28 AM, Curtiss Howard
wrote:

> On Tue, Jun 16, 2009 at 10:45 AM, Leonardo Uribe wrote:
> > Hi
> >
> > If you are taking about the tests that does not allowed compile tomahawk
> in
> > offline mode, it was fixed yesterday.
> >
> > regards
> >
> > Leonardo Uribe
> >
>
> No, I was thinking more about how the 2.0 impl tests don't work :).
>
>
> Curtiss Howard
>

Re: [MyFaces 2.0] discussion on alpha plans

[Simon Lessard]

We use the Facelets codebase, we just have to rename the package (already
done), use the HandlerDelegate ... thing ... and implement the Facelets VDL.
Those are not part of "standard" Facelets with existing ASL 2.0 code.


~ Simon

On Tue, Jun 9, 2009 at 11:22 AM, Matthias Wessendorf wrote:

> On Tue, Jun 9, 2009 at 8:20 AM, Ganesh wrote:
> > Hi,
> >
> > Facelets are apache 2.0 licensed,
>
> correct
>
> > why do we reinvent them?
>
> they added stuff for JSF 2.0
>
> e.g.  etc
> (but didn't put it into the Apache licensed version)
>
> >
> > Best regards,
> > Ganesh
> >
> > Simon Lessard schrieb:
> >>
> >> Hi,
> >>
> >> On my side I'll try to work and finish Facelets part within 2 weeks,
> fater
> >> than that is impossible for me atm.
> >>
> >>
> >> Regards,
> >>
> >> ~ Simon
> >>
> >> On Tue, Jun 9, 2009 at 9:53 AM, Werner Punz  >> <mailto:werner.p...@gmail.com>> wrote:
> >>
> >>Matthias Wessendorf schrieb:
> >>
> >>regarding tree visitor, this may help:
> >>
> >>https://issues.apache.org/jira/browse/TRINIDAD-1368
> >>
> >>Thanks for the link, I will get it and compare it to what I have...
> >>I assume there wont be too much which I still can integrated in
> >>the PartialVisitContext since I am rather optimized already and
> >>bound by the spec!
> >>
> >>
> >>Werner
> >>
> >>
> >>
> >>
> >>
> >>-Matthias
> >>
> >>On Tue, Jun 9, 2009 at 6:37 AM, Werner
> >>Punzmailto:werner.p...@gmail.com>>
> wrote:
> >>
> >>Michael Concini schrieb:
> >>
> >>Wasn't there a plan to have some of the partial tree
> >>traversal work done
> >>as part of the Google Summer of Code?  I seem to
> >>recall some discussion
> >>around this awhile back (don't have time to dig
> >>through the mailing list
> >>archives right now to check).  Does anybody remember
> >>what the plan was with
> >>Google SoC?
> >>
> >>Interesting question, but I assume I only have a small
> >>subset of the needed
> >>functionality implemented, the one we need for PPR so,
> >> I will commit my tomorrow as soon as I have tested it,
> >>whoever wants to do
> >>something in GSOC can pick it up and refine it. But have
> >>in mind, my work
> >>currently only coveres the area of providing a
> >>PartialVisitContext so that I
> >>have a complete state for PPR in this area!
> >>If someone comes with a better solution I dont have any
> >>problem dropping the
> >>code again ;-)
> >>
> >>
> >>Werner
> >>
> >>
> >>
> >>Werner Punz wrote:
> >>
> >>Michael Concini schrieb:
> >>
> >>All,
> >>
> >>I thought it might be a good time to raise the
> >>issue of solidifying a
> >>plan for the MyFaces 2.0 alpha release now
> >>that we've had a little time to
> >>work with the release candidate draft of the
> >>spec.  What are the thoughts in
> >>the community with respect to what should be
> >>included in an alpha release as
> >>well as what the time frame should be for a
> >>release.  If we can come up with
> >>a target date as well as specific 2.0 features
> >>we want to target for
> >>inclusion, that should help in prioritizing
> >>the remaining work.
> >> From my end, I'd love to see a working
> >>runtime in some form by the end
> >>of August if that's reasonable.  As for
> >> 

Re: [MyFaces 2.0] discussion on alpha plans

[Simon Lessard]

Hi,

On my side I'll try to work and finish Facelets part within 2 weeks, fater
than that is impossible for me atm.


Regards,

~ Simon

On Tue, Jun 9, 2009 at 9:53 AM, Werner Punz  wrote:

> Matthias Wessendorf schrieb:
>
>> regarding tree visitor, this may help:
>>
>> https://issues.apache.org/jira/browse/TRINIDAD-1368
>>
>>  Thanks for the link, I will get it and compare it to what I have...
> I assume there wont be too much which I still can integrated in the
> PartialVisitContext since I am rather optimized already and bound by the
> spec!
>
>
> Werner
>
>
>
>
>
>  -Matthias
>>
>> On Tue, Jun 9, 2009 at 6:37 AM, Werner Punz wrote:
>>
>>> Michael Concini schrieb:
>>>
 Wasn't there a plan to have some of the partial tree traversal work done
 as part of the Google Summer of Code?  I seem to recall some discussion
 around this awhile back (don't have time to dig through the mailing list
 archives right now to check).  Does anybody remember what the plan was
 with
 Google SoC?

  Interesting question, but I assume I only have a small subset of the
>>> needed
>>> functionality implemented, the one we need for PPR so,
>>>  I will commit my tomorrow as soon as I have tested it, whoever wants to
>>> do
>>> something in GSOC can pick it up and refine it. But have in mind, my work
>>> currently only coveres the area of providing a PartialVisitContext so
>>> that I
>>> have a complete state for PPR in this area!
>>> If someone comes with a better solution I dont have any problem dropping
>>> the
>>> code again ;-)
>>>
>>>
>>> Werner
>>>
>>>
>>>
>>>  Werner Punz wrote:

> Michael Concini schrieb:
>
>> All,
>>
>> I thought it might be a good time to raise the issue of solidifying a
>> plan for the MyFaces 2.0 alpha release now that we've had a little
>> time to
>> work with the release candidate draft of the spec.  What are the
>> thoughts in
>> the community with respect to what should be included in an alpha
>> release as
>> well as what the time frame should be for a release.  If we can come
>> up with
>> a target date as well as specific 2.0 features we want to target for
>> inclusion, that should help in prioritizing the remaining work.
>>  From my end, I'd love to see a working runtime in some form by the
>> end
>> of August if that's reasonable.  As for content, that is definitely
>> more of
>> an open question. Here is my top list of what I would like to see be
>> at
>> least partially functional for an alpha release.
>> -backwards compatibility with JSF 1.x apps
>> -base support for facelets and composite components
>> -AJAX support (should hopefully be in pretty good shape here thanks to
>> Ganesh and team)
>> -System event support
>> -Partial view traversal
>>
>> Thoughts/concerns/objections?
>>
>> -Mike
>>
>>  None from my side not sure how far Ganesh is with his ajax tag!
> The scripts already are in pretty good shape and functionalitywise well
> ahead of the RI ;-)
>
> As for partial Tree traversal minor sidequestion? Has anyone started to
> work on this, because I have started to implement the partial visit
> context
> (I have to recheck the jira for this, because I opened an issue for
> this
> under partial render response issue 2116/2241)!
>
> https://issues.apache.org/jira/browse/MYFACES-2241
>
> I will commit my code around tomorrow, it is basically done
> but needs some testing!
>
>
>
> Werner
>
>
>

>>>
>>
>>
>>
>

Re: [VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))

[Simon Lessard]

+1

On Thu, May 28, 2009 at 2:23 AM, Matthias Wessendorf wrote:

> sure!
>
> On Thu, May 28, 2009 at 6:34 AM, Leonardo Uribe  wrote:
> > +1, but just a small suggestion. Right now I'm running the necessary
> steps
> > for release myfaces core 1.2.7, core 1.1.7, so I would like if it is
> > possible to delay this change after the release.
> >
> > regards
> >
> > Leonardo Uribe
> >
> > 2009/5/27 Cagatay Civici 
> >>
> >> +1 for sure
> >>
> >> On Wed, May 27, 2009 at 8:53 AM, Bruno Aranda 
> >> wrote:
> >>>
> >>> +1 sounds good to me
> >>>
> >>> 2009/5/27 Matthias Wessendorf :
> >>> > so, there are no objections in making the MyFaces 2.0 efforts become
> >>> > trunk ?
> >>> >
> >>> > -Matthias
> >>> >
> >>> > On Fri, May 22, 2009 at 9:10 PM, Bernd Bohmann
> >>> >  wrote:
> >>> >> Hello,
> >>> >>
> >>> >> +1
> >>> >>
> >>> >> I would prefer
> >>> >>
> >>> >> /trunk -> 2.0
> >>> >> /branches/myfaces-1.1.x
> >>> >> /branches/myfaces-1.2.x
> >>> >>
> >>> >> because we are not using cvs anymore
> >>> >>
> >>> >> and the path already contains
> >>> >>
> >>> >> http://svn.apache.org/repos/asf/myfaces/core/
> >>> >>
> >>> >> maybe we can omit the 'myfaces' in the branch name.
> >>> >>
> >>> >> Regards
> >>> >>
> >>> >> Bernd
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Fri, May 22, 2009 at 5:27 PM, Matthias Wessendorf
> >>> >>  wrote:
> >>> >>> actually, I agree with Bernd.
> >>> >>>
> >>> >>> For the following layout:
> >>> >>>
> >>> >>> /trunk -> 2.0
> >>> >>> /branches/myfaces_1_1_x
> >>> >>> /branches/myfaces_1_2_x
> >>> >>>
> >>> >>> Two reasons for way making 2.0 trunk:
> >>> >>> -most current development is on-going in 2.0 (new spec)
> >>> >>> -most commits are going to the 2.0 branch (so, let's make it trunk)
> >>> >>>
> >>> >>>
> >>> >>> So, I am +1 on the above "svn layout"
> >>> >>>
> >>> >>>
> >>> >>> -Matthias
> >>> >>>
> >>> >>>
> >>> >>> On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf
> >>> >>>  wrote:
> >>>  from Bernd, on a different thread:
> >>> 
> >>>  Hello,
> >>> 
> >>>  I would suggest following layout
> >>> 
> >>>  1.1.x branch/1.1.x
> >>>  1.2.x branch/1.2.x
> >>>  2.0.x trunk
> >>> 
> >>>  because the 2.0.x version is in development the other branches are
> >>>  only in bugfix state.
> >>> 
> >>> 
> >>> 
> >>> 
> >>>  On Fri, May 15, 2009 at 1:13 PM, Werner Punz <
> werner.p...@gmail.com>
> >>>  wrote:
> >>> > Matthias Wessendorf schrieb:
> >>> >>
> >>> >> Hi,
> >>> >> ...
> >>> >>>
> >>> >>> Ok, I filed this:
> >>> >>> https://issues.apache.org/jira/browse/INFRA-2053
> >>> >>>
> >>> >>> maybe we should also think about making the JSF 1.1.x stuff a
> >>> >>> branch ...
> >>> >>> (since we already work on 2.0.x)
> >>> >>
> >>> >> what do people think if the 1.2 stuff becomes "trunk"
> >>> >> And the following efforts are on a branch:
> >>> >> -2.0.x
> >>> >> -1.1.x
> >>> >>
> >>> > +1
> >>> >
> >>> >
> >>> 
> >>> 
> >>> 
> >>>  --
> >>>  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
> >>> >>>
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Matthias Wessendorf
> >>> >
> >>> > blog: http://matthiaswessendorf.wordpress.com/
> >>> > sessions: http://www.slideshare.net/mwessendorf
> >>> > twitter: http://twitter.com/mwessendorf
> >>> >
> >>
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: [TRINIDAD][API] JIRA-1474 Add Window abstraction to Trinidad

[Simon Lessard]

Sounds acceptable then.

~ Simon

On Sun, May 17, 2009 at 9:09 PM, Blake Sullivan
wrote:

>  Simon Lessard said the following On 5/17/2009 6:19 AM PT:
>
> Hi Blake,
>
> *Prefer the same what?  Are you talking about the ExternalContext?*
>
> I meant placing register the listeners the Window itself, not the Manager,
> same as isNew.
>
> The difference between isNew() and the addition of the listeners is that
> the the application doesn't have a good place to add a listener on a window
> instance except in some form of listener callback itself.  The reason is
> that the application often isn't directly involved in the creation of new
> windows--for example the user hits control-N in IE and a new window is
> created.  Other than using listener injection, which would be applied to all
> windows anyway, it isn't clear how an application could add a listener when
> a particular window instance is created.  It seemed easier for the
> application to add a listener that applies to all windows and let the
> application ignore events on any windows it doesn't care about.
>
> -- Blake Sullivan
>
>
>
>
> ~ Simon
>
> On Sat, May 16, 2009 at 1:18 AM, Blake Sullivan  > wrote:
>
>> Simon Lessard said the following On 5/15/2009 12:35 PM PT:
>>
>> Hi Blake,
>>
>> I'm + 1 with the idea and the general API, but I have some concerns:
>>
>>1. I don't really like the API to expose a read only map through
>>WindowManager.getWindows, I would prefer
>>WindowManager.getWindowIds(ExternalContext) and
>>WindowManager.getWindow(ExternalContext, String);
>>
>>  Is your worry over that the Map is read only?  The two separate methods
>> prevent the developer from leveraging the Map interface.
>>
>>
>>1. WindowListener should be an interface extending EventListener one
>>of its subclasses;
>>
>>  Fair enough, the rationale for making this an abstract class was so we
>> could add more event types later.  However, since the WindowManager class is
>> itself an abstract class we could add more event listener interfaces later
>> to the WindowManager later, so I agree that the interface is fine
>>
>>
>>1. Either WindowListener or WindowLifecycleEvent is wrongly named from
>>a JSF point of view (althoguh it could be potentially correctly named in
>>Swing). All JSF Listener handle events with the exact same name as the
>>listener, but with Listener changed to Event, so it should either be
>>WindowLifecycleListener or WindowEvent for the API to be coherent with the
>>usual JSF nomenclature.
>>
>>  See above.  I agree that if we use an interface then the listener class
>> must be WindowLifecycleListener
>>
>>
>>1. WindowListener method is not properly named. Pretty much as above,
>>in JSF all listener methods are called process so it should 
>> either
>>be public void processWindowEvent or processWindowLifecycleEventdepending 
>> on
>>the resolution of the previous point;
>>2. The process method parameters do not match the usual listener
>>convention to receive a single event object. Would it be possible to place
>>the ExternalContext instance in the event?
>>
>>  I guess we could put the ExternalContext in the event, though the field
>> will need to be transient and getExternalContext() method on the event would
>> need to document that it might return null if the event has been
>> serialized.  All of which is pretty gross.  In this case the extra parameter
>> is much cleaner.  I believe that the convention is really to aid Java Beans
>> design tools using introspection and would prefer cleanliness in this case.
>>
>>
>>1. I would prefer to see WindowManager.isCurrentWindowNew as
>>Window.isNew, it's more OOP correct;
>>
>>  OK.  The original implementation only tracked the new status of the
>> current window, which was tracked by the WindowManager (which is why the
>> WindowManager).  However, due to the need to answer this question in the
>> face of redirects and other weirdness, the Windows in the implementation I
>> have been testing do maintain their "new" state, so I agree that it makes
>> more sense for the Window to answer this question.
>>
>>
>>1. Actually I would prefer the same for the
>>add/get/removeWindowListener
>>
>>  Prefer the same what?  Are you talking about the ExternalContext?
>>
>> Thanks for the helpful feedback.
>>
>> --Blake Sullivan
>>
>>
>> Regards,
>&

Re: [TRINIDAD][API] JIRA-1474 Add Window abstraction to Trinidad

[Simon Lessard]

Hi Blake,

*Prefer the same what?  Are you talking about the ExternalContext?*

I meant placing register the listeners the Window itself, not the Manager,
same as isNew.


~ Simon

On Sat, May 16, 2009 at 1:18 AM, Blake Sullivan
wrote:

>  Simon Lessard said the following On 5/15/2009 12:35 PM PT:
>
> Hi Blake,
>
> I'm + 1 with the idea and the general API, but I have some concerns:
>
>1. I don't really like the API to expose a read only map through
>WindowManager.getWindows, I would prefer
>WindowManager.getWindowIds(ExternalContext) and
>WindowManager.getWindow(ExternalContext, String);
>
>  Is your worry over that the Map is read only?  The two separate methods
> prevent the developer from leveraging the Map interface.
>
>
>1. WindowListener should be an interface extending EventListener one of
>its subclasses;
>
>  Fair enough, the rationale for making this an abstract class was so we
> could add more event types later.  However, since the WindowManager class is
> itself an abstract class we could add more event listener interfaces later
> to the WindowManager later, so I agree that the interface is fine
>
>
>1. Either WindowListener or WindowLifecycleEvent is wrongly named from
>a JSF point of view (althoguh it could be potentially correctly named in
>Swing). All JSF Listener handle events with the exact same name as the
>listener, but with Listener changed to Event, so it should either be
>WindowLifecycleListener or WindowEvent for the API to be coherent with the
>usual JSF nomenclature.
>
>  See above.  I agree that if we use an interface then the listener class
> must be WindowLifecycleListener
>
>
>1. WindowListener method is not properly named. Pretty much as above,
>in JSF all listener methods are called process so it should 
> either
>be public void processWindowEvent or processWindowLifecycleEventdepending 
> on
>the resolution of the previous point;
>2. The process method parameters do not match the usual listener
>convention to receive a single event object. Would it be possible to place
>the ExternalContext instance in the event?
>
>  I guess we could put the ExternalContext in the event, though the field
> will need to be transient and getExternalContext() method on the event would
> need to document that it might return null if the event has been
> serialized.  All of which is pretty gross.  In this case the extra parameter
> is much cleaner.  I believe that the convention is really to aid Java Beans
> design tools using introspection and would prefer cleanliness in this case.
>
>
>1. I would prefer to see WindowManager.isCurrentWindowNew as
>Window.isNew, it's more OOP correct;
>
>  OK.  The original implementation only tracked the new status of the
> current window, which was tracked by the WindowManager (which is why the
> WindowManager).  However, due to the need to answer this question in the
> face of redirects and other weirdness, the Windows in the implementation I
> have been testing do maintain their "new" state, so I agree that it makes
> more sense for the Window to answer this question.
>
>
>1. Actually I would prefer the same for the
>add/get/removeWindowListener
>
>  Prefer the same what?  Are you talking about the ExternalContext?
>
> Thanks for the helpful feedback.
>
> --Blake Sullivan
>
>
>
> Regards,
>
> ~ Simon
>
>
> On Fri, May 15, 2009 at 3:09 PM, Blake Sullivan  > wrote:
>
>> Here is the proposed api:
>>
>> package org.apache.myfaces.trinidad.context;
>>
>>
>> /**
>> * Represents a Window in the current user's Session.  Windows are created
>> and vended
>> * by the Session's WindowManager and the Window for the current request is
>> * available from WindowManager.getCurrentWindow
>> * @see WindowManager#getCurrentWindow
>> */
>> public abstract class Window implements Serializable
>> {
>>  /**
>>  * 
>>  * Represents the current state of the Window.  Windows start out
>> OPEN,
>>  * when the current window's document is being unloaded, they move to the
>> UNLOADING
>>  * state and then either move back to the OPEN state if the
>> Window's content
>>  * is populated with a new document from the same application, or to the
>> CLOSED
>>  * state if it is not.
>>  * 
>>  * This represents the framework's best guess at the current status of the
>> Window.
>>  * 
>>  */
>>  public enum LifecycleState
>>  {
>>   /** The Window is currently open */
>>   OPEN,
>>
>>   /** The 

Re: [TRINIDAD][API] JIRA-1474 Add Window abstraction to Trinidad

[Simon Lessard]

Hi Blake,

I'm + 1 with the idea and the general API, but I have some concerns:

   1. I don't really like the API to expose a read only map through
   WindowManager.getWindows, I would prefer
   WindowManager.getWindowIds(ExternalContext) and
   WindowManager.getWindow(ExternalContext, String);
   2. WindowListener should be an interface extending EventListener one of
   its subclasses;
   3. Either WindowListener or WindowLifecycleEvent is wrongly named from a
   JSF point of view (althoguh it could be potentially correctly named in
   Swing). All JSF Listener handle events with the exact same name as the
   listener, but with Listener changed to Event, so it should either be
   WindowLifecycleListener or WindowEvent for the API to be coherent with the
   usual JSF nomenclature.
   4. WindowListener method is not properly named. Pretty much as above, in
   JSF all listener methods are called process so it should either be
   public void processWindowEvent or processWindowLifecycleEventdepending on
   the resolution of the previous point;
   5. The process method parameters do not match the usual listener
   convention to receive a single event object. Would it be possible to place
   the ExternalContext instance in the event?
   6. I would prefer to see WindowManager.isCurrentWindowNew as
   Window.isNew, it's more OOP correct;
   7. Actually I would prefer the same for the add/get/removeWindowListener


Regards,

~ Simon


On Fri, May 15, 2009 at 3:09 PM, Blake Sullivan
wrote:

> Here is the proposed api:
>
> package org.apache.myfaces.trinidad.context;
>
>
> /**
> * Represents a Window in the current user's Session.  Windows are created
> and vended
> * by the Session's WindowManager and the Window for the current request is
> * available from WindowManager.getCurrentWindow
> * @see WindowManager#getCurrentWindow
> */
> public abstract class Window implements Serializable
> {
>  /**
>  * 
>  * Represents the current state of the Window.  Windows start out
> OPEN,
>  * when the current window's document is being unloaded, they move to the
> UNLOADING
>  * state and then either move back to the OPEN state if the
> Window's content
>  * is populated with a new document from the same application, or to the
> CLOSED
>  * state if it is not.
>  * 
>  * This represents the framework's best guess at the current status of the
> Window.
>  * 
>  */
>  public enum LifecycleState
>  {
>   /** The Window is currently open */
>   OPEN,
>
>   /** The Window is being unloaded */
>   UNLOADING,
>
>   /** The Window is believed to be closed, either because the window was
> explicitly closed
>*  or because the window is suspected to have been closed
>*/
>   CLOSED
>  }
>
>  /**
>  * Represents how the window is used in the application
>  */
>  public enum Usage
>  {
>   /** Used as a top-level application window */
>   FRAME,
>
>   /** Used as a dialog */
>   DIALOG
>  }
>
>  /**
>  * @return The unique identifier for this Window within the Session
>  */
>  public abstract String getId();
>
>  /**
>  * @return The current state of the Window
>  */
>  public abstract LifecycleState getLifecycleState();
>
>  /**
>  * Returns the Usage of the Window--either a top-level frame or a dialog
>  * @return how the window is used
>  */
>  public abstract Usage getUsage();
> }
>
> /**
> * 
> * Manages the set of Windows currently in the Session and allows listeners
> on the Windows'
> * lifecycles to be registered.
> * 
> * @see org.apache.myfaces.trinidad.context.RequestContext#getWindowManager
> */
> abstract public class WindowManager
> {
>  /**
>  * @param extContext ExternalContext so that the WindowManager may be
> called before the
>  * FacesContext is available
>  * @return The Window that contains the document making the current request
>  */
>  public abstract Window getCurrentWindow(ExternalContext extContext);
>
>  /**
>  * @param extContext ExternalContext so that the WindowManager may be
> called before the
>  * FacesContext is available
>  * @return true if the Window making the current request is
> newly created.
>  */
>  public abstract boolean isCurrentWindowNew(ExternalContext extContext);
>
>  /**
>  * @param extContext ExternalContext so that the WindowManager may be
> called before the
>  * FacesContext is available
>  * @return The Unmodifiable Map of WindowIds to Windows
>  */
>  public abstract Map getWindows(ExternalContext
> extContext);
>
>  /**
>  * 
>  * Registers a listener that will be informed of changes to the Lifecylce
> state of any of
>  * the known Windows.
>  * 
>  * 
>  * Window listeners may be registered automatically by adding a file
>  * containing the names of the classes implementing the WindowListener in a
> file named
>  * org.apache.myfaces.trinidad.event.WindowListener inside of
>  * the META_INF/services directory.
>  * 
>  * @param extContext ExternalContext so that the WindowManager may be
> called before the
>  * FacesContext is available
>  * @param windowListener
>  */

Re: [myfaces 2.0] ProjectStage extension ?

[Simon Lessard]

Well I guess you're right, there's no way that the property will be set
during the tests.

On Thu, May 14, 2009 at 5:52 PM, Matthias Wessendorf
wrote:

> I guess the tck has no org.apache.** cfg param as sys prop
>
> Sent from my iPod.
>
> Am 14.05.2009 um 22:45 schrieb Simon Lessard :
>
> Sounds pretty decent to me, we'll just have to make sure we still pass the
> TCK after though since the spec also define the default.
>
> ~ Simon
>
> On Thu, May 14, 2009 at 2:27 PM, Matthias Wessendorf <
> mwessend...@gmail.com> wrote:
>
>> Of course ordering after the standard...
>>
>> Sent from my iPod.
>>
>> Am 14.05.2009 um 20:18 schrieb Gerhard Petracek <
>> gerhard.petra...@gmail.com>:
>>
>> +1
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2009/5/14 Matthias Wessendorf <  
>> mat...@apache.org>
>>
>>> Hey,
>>>
>>> currently ProjectStage is a bit poor, it does not provide support for
>>> system props... In order to make that happen we (myfaces) could provide
>>> an extension for that...
>>>
>>> so that we would support something like:
>>>
>>> projectStage = System.getProperty("org.apache.myfaces.PROJECT_STAGE")
>>>
>>> what do you think ?
>>>
>>> (as far as I know this is present in JSF 2.1 as well)
>>>
>>> -Matthias
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: 
>>> <http://matthiaswessendorf.wordpress.com/><http://matthiaswessendorf.wordpress.com/>
>>> http://matthiaswessendorf.wordpress.com/
>>> sessions: 
>>> <http://www.slideshare.net/mwessendorf><http://www.slideshare.net/mwessendorf>
>>> http://www.slideshare.net/mwessendorf
>>> twitter: <http://twitter.com/mwessendorf><http://twitter.com/mwessendorf>
>>> http://twitter.com/mwessendorf
>>>
>>
>>
>

Re: [myfaces 2.0] ProjectStage extension ?

[Simon Lessard]

Sounds pretty decent to me, we'll just have to make sure we still pass the
TCK after though since the spec also define the default.

~ Simon

On Thu, May 14, 2009 at 2:27 PM, Matthias Wessendorf
wrote:

> Of course ordering after the standard...
>
> Sent from my iPod.
>
> Am 14.05.2009 um 20:18 schrieb Gerhard Petracek <
> gerhard.petra...@gmail.com>:
>
> +1
>
> regards,
> gerhard
>
>
>
> 2009/5/14 Matthias Wessendorf < mat...@apache.org>
>
>> Hey,
>>
>> currently ProjectStage is a bit poor, it does not provide support for
>> system props... In order to make that happen we (myfaces) could provide
>> an extension for that...
>>
>> so that we would support something like:
>>
>> projectStage = System.getProperty("org.apache.myfaces.PROJECT_STAGE")
>>
>> what do you think ?
>>
>> (as far as I know this is present in JSF 2.1 as well)
>>
>> -Matthias
>>
>> --
>> Matthias Wessendorf
>>
>> blog: 
>> http://matthiaswessendorf.wordpress.com/
>> sessions: 
>> http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
>

Re: [TRINIDAD] org.apache.myfaces.trinidadinternal.ENABLE_IMAGE_AGGREGATION

[Simon Lessard]

+1

On Mon, May 11, 2009 at 7:21 PM, Jeanne Waldman
wrote:

>  +1 to the name
> Is everyone ok with trinidadinternal plus a comment staying it is private
> being enough to make this 'private' so that we are free to remove it and/or
> change the default behavior after it has been tested long enough?
> I'm ok with it.
>
> Here's a link to the JIRA issue:
> https://issues.apache.org/jira/browse/TRINIDAD-1442
>
> Jeanne
>
> Korhan Bircan wrote, On 5/11/2009 4:07 PM PT:
>
>  Hello,
>
> To implement Trinidad-1442 "Aggregate single image to send to client" I
> need a new context parameter to turn the feature on and off in case there
> are any bugs early on. I want to make it private and remove it once the
> feature is fully tested.  If the feature works properly it will help
> performance and should always be on.
>
> Currently I'm using a parameter in web.xml called
> "org.apache.myfaces.trinidadinternal.ENABLE_IMAGE_AGGREGATION". What do
> you think about this?
>
> The affected files are:
> org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache.java
> org.apache.myfaces.trinidadinternal.style.cache.ImageStrip.java (new)
> org.apache.myfaces.trinidadinternal.style.cache.ImageStripIcon.java (new)
> org.apache.myfaces.trinidadinternal.style.cache.ImageStripUtils.java (new)
> org.apache.myfaces.trinidadinternal.style.util.CSSGenerationUtils.java
>
> Thanks,
>
> --
> Korhan
> 650.506.7786
>
>

Re: h:head and h:body in JSF 2.0 + javax.faces.ViewState in the response

[Simon Lessard]

Not sure on my side, I'm really not into AJAX. I followed the discussions,
but really not deeply enough to get that kind of detail. :(

~ Simon

On Wed, May 6, 2009 at 1:02 PM, Werner Punz  wrote:

> Ok Since Ganesh pointed it out, this is even better.
> We probably wont need a parser at all.
> The section describing javax.faces.ViewRoot as
> ppr update id basically omits the entire parsing stage.
> They way I interpete it for now is that we can
> serve the innerHTML of the html tag and have
> a simple innerHTML replacement (with optional
> script triggers, for embedded scripts, which also
> can be covered by a following eval part)
>
> So this means the work is entirely offloaded
> to the responseWriter.
> I have committed my parser, but I am more than glad
> to rip it out again and drop it into oblivion
> (I am always a big fan of throwing away code to reduce
> the codesize)
>
>
> Another issue:
> The spec seems to have changed regarding the viewState handling on the
> client side in the pr
> pr case last minute: It seems that it now is just changing the viewState of
> the submitting form of the ppr request. Is this correct or an errata in the
> latest spec?
>
> If yes do we still have to add missing viewState elements if the form does
> not have one, and is the entire, change all viewstate elements part entirely
> dropped?
>
> The last jira entries did not show any big changes except for
> s/identifier/name which we requested?
>
> Can anyone of the EG guys comment on this?
>
>
> Werner
>
>
>
> Werner Punz schrieb:
>
>> Looks ok to me, the parsing is not omitted but instead
>> the option to render the head and body without parsing is added.
>> Either way, I have the parser in place now and will commit it tomorrow.
>> So we have the harder part in place and working and it is fast enoguh.
>>
>> 80.000 characters are handled within 1.5 seconds which is fast enough!
>> I will commit it tomorrow since I am currently at a customer...
>>
>>
>> Werner
>>
>>
>>
>> Roger Kitain schrieb:
>>
>>> Ganesh wrote:
>>>

 [2] The jsdoc on javax.faces.response defines a behaviour for update
 elements with the id javax.faces.ViewRoot. By testing with the RI I
 found out that this behaviour is triggered if an AJAX requests triggers
 a naviagtion rule that leads to a different page. It's a cool thing to
 have a well defined behaviour in this case, but the spec doesn't define
 it. It's just what Mojarra does. Can you please add a paragraph that
 defines the circumstances under which the server has to respond with
 javax.faces.ViewRoot?

>>> This is now fixed - see:
>>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=554
>>>

 [3] In the javax.faces.ViewRoot case Mojarra returns a complete document
 with DOCTYPE, html, head and body. It is left to the Javascript
 implementation to separate these and replace the head and body sections.
 This is a tedious task involving a parser that deals with html comments,
 Javascript comments and CDATA sections within the HTML page. The
 Javascript code Mojarra brings for this is unsufficient and fails for
 many cases. We are currently working on a parser. Things would be a lot
 easier if the spec would force the server to return separate CDATA
 blocks within javax.faces.ViewRoot for the head and the body tag and to
 omit the html tag and the DOCROOT. This can't be too hard to implement,
 because head and body are rendered by h:head and h:body. Can you please
 define the format for javax.faces.ViewRoot to contain 2 CDATA sections, 1
 optional with the head tag and 1 required with the body tag?

>>> Fixed- See:
>>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=557
>>>

 Best Regards,
 Ganesh Jung


>>>
>>>
>>
>>
>

Re: MyFaces2.0 compile error in javax.faces.component._SelectItemsIterator

[Simon Lessard]

That's good to know. Maybe we should wikify that fact for MyFaces in
general?

~ Simon

On Wed, May 6, 2009 at 5:11 AM, Werner Punz  wrote:

> I assume the problem with Netbeans (which in my opinion currently has the
> best maven support) is that its maven implementation to my knowledge
> is rather old. So things which work on Maven 2.0.9 or 2.0.10 do not work
> often on Netbeans which relies on a way older maven implementation.
>
> Not sure if you can replace the integrated netbeans maven with
> an external one.
>
>
> Things probably will become better once Netbeans 6.7 is out
>
> Werner
>
>
> Matthias Wessendorf schrieb:
>
>  On Wed, May 6, 2009 at 9:03 AM, Ganesh  wrote:
>>
>>> Hi Simon,
>>>
>>> It's the Netbeans IDE's maven plugin that doesn't recognize the generated
>>> classes path and thus shows compile errors. I've switched to Eclipse
>>> (needed
>>> to add the maven plugin and enable dependency management and nested
>>> modules)
>>> and things work fine :-)
>>>
>>
>> real man's IDE ;-)
>> Funny that it does not work in Netbeans. The IDEs I am using (JDEV and
>> Eclipse) understand
>> those generated artifcats. Tools just should work, eh ? :)
>>
>>  Best Regards,
>>> Ganesh
>>>
>>> Simon Lessard schrieb:
>>>
>>>> Hi,
>>>>
>>>> The class gets generated by a Maven plugin using _UISelectItems as a
>>>> base.
>>>> It works fine for me. Did you checkout also the mavin plugin projects?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> ~ Simon
>>>>
>>>> On Sun, Apr 19, 2009 at 4:30 PM, Ganesh >>> <mailto:gan...@j4fry.org>> wrote:
>>>>
>>>>   Hi Simon,
>>>>
>>>>   I have run mvn install. In the API
>>>>   javax.faces.component._SelectItemsIterator contains references to
>>>>   class UISelectItems which doesn't exists. There is a class named
>>>>   javax.faces.component._UISelectItems and if you wouldn't say it
>>>>   compiles fine for you I'd think it's a typo in
>>>>   javax.faces.component._SelectItemsIterator. Similar issues exist
>>>>   for UIMessage and UIMessages.
>>>>
>>>>   Here's a link to the ViewVC of the 2_0_0 branch. I think it
>>>>   supports that there is _UISelectItems, but no UISelectItems and
>>>>   that _SelectItemsIterator references UISelectItems:
>>>>
>>>>
>>>>
>>>> http://svn.apache.org/viewvc/myfaces/core/branches/2_0_0/api/src/main/java/javax/faces/component/
>>>>
>>>>   Can you please check this again?
>>>>
>>>>   Best Regards,
>>>>   Ganesh
>>>>
>>>>   Simon Lessard schrieb:
>>>>
>>>>   Hi Ganesh,
>>>>
>>>>   I think you forgot to execute mvn install on the build maybe
>>>>   because it compiles fine for me.
>>>>
>>>>   As for running the whole thing I don't think it would be
>>>>   working yet since some Lifecycle phases were already modified
>>>>   to use the new Ajax API on partial request, but there's no
>>>>   impl for that code yet. Once the partial context and writer as
>>>>   well as JSP VDL are implemented then I think a simpel test
>>>>   case will be runnable.
>>>>
>>>>
>>>>   Regards,
>>>>
>>>>   ~ Simon
>>>>
>>>>
>>>>
>>
>>
>>
>

Re: FYI: javax.inject* standard ...

[Simon Lessard]

I agree, it should have been more abstract to start with, and not depend on
JSF for conversation scope either. Actually, the more I think about it, the
more I think that it should have been JSF extending 299 with conversation
scope through WebBeans custom scope feature and it should have been the same
for EJB 3. Currently it seems to me that the dependency links with JSR-299
are all in the opposite direction that they should have been.

~ Simon


On Tue, May 5, 2009 at 2:02 PM, Simon Lessard wrote:

> That's true, but I think most JSR-299 impl can run outside JEE environment
> already. Many specs started in EE and ended in SE 1 or 2 version of the SDK
> later.
>
>
> On Tue, May 5, 2009 at 1:57 PM, Matthias Wessendorf wrote:
>
>> the big failure of the JSR 299 is that it just lives in JavaEE land.
>>
>> Best would have been to introduce a flexible DI API in SE land.
>> This could be extended in all the different profiles. So, 299 could
>> have just been a *consumer* of that flexible DI in order to extend
>> it and add the things that are needed for EJB and all the other EE things.
>>
>> just my $0.02
>>
>> -M
>>
>> On Tue, May 5, 2009 at 7:54 PM, Simon Lessard 
>> wrote:
>> > Weird, it certainly overlaps BIG time, most of what their spec seem to
>> have
>> > is already in JSR-299 too... Maybe I'm missing something...
>> >
>> > On Tue, May 5, 2009 at 1:45 PM, Matthias Wessendorf 
>> > wrote:
>> >>
>> >> FYI
>> >>
>> >>
>> >> -- Forwarded message --
>> >> From: Matthias Wessendorf 
>> >> Date: Tue, May 5, 2009 at 7:34 PM
>> >> Subject: FYI: javax.inject* standard ...
>> >> To: openwebbeans-...@incubator.apache.org
>> >> Cc: Pete Muir 
>> >>
>> >>
>> >> FYI:
>> >> http://google-code-updates.blogspot.com/2009/05/javaxinjectinject.html
>> >>
>> >> what does this mean to JSR 299 ?
>> >>
>> >> --
>> >> 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
>> >
>> >
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
>

Re: FYI: javax.inject* standard ...

[Simon Lessard]

That's true, but I think most JSR-299 impl can run outside JEE environment
already. Many specs started in EE and ended in SE 1 or 2 version of the SDK
later.

On Tue, May 5, 2009 at 1:57 PM, Matthias Wessendorf wrote:

> the big failure of the JSR 299 is that it just lives in JavaEE land.
>
> Best would have been to introduce a flexible DI API in SE land.
> This could be extended in all the different profiles. So, 299 could
> have just been a *consumer* of that flexible DI in order to extend
> it and add the things that are needed for EJB and all the other EE things.
>
> just my $0.02
>
> -M
>
> On Tue, May 5, 2009 at 7:54 PM, Simon Lessard 
> wrote:
> > Weird, it certainly overlaps BIG time, most of what their spec seem to
> have
> > is already in JSR-299 too... Maybe I'm missing something...
> >
> > On Tue, May 5, 2009 at 1:45 PM, Matthias Wessendorf 
> > wrote:
> >>
> >> FYI
> >>
> >>
> >> -- Forwarded message --
> >> From: Matthias Wessendorf 
> >> Date: Tue, May 5, 2009 at 7:34 PM
> >> Subject: FYI: javax.inject* standard ...
> >> To: openwebbeans-...@incubator.apache.org
> >> Cc: Pete Muir 
> >>
> >>
> >> FYI:
> >> http://google-code-updates.blogspot.com/2009/05/javaxinjectinject.html
> >>
> >> what does this mean to JSR 299 ?
> >>
> >> --
> >> 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
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: FYI: javax.inject* standard ...

[Simon Lessard]

Weird, it certainly overlaps BIG time, most of what their spec seem to have
is already in JSR-299 too... Maybe I'm missing something...

On Tue, May 5, 2009 at 1:45 PM, Matthias Wessendorf wrote:

> FYI
>
>
> -- Forwarded message --
> From: Matthias Wessendorf 
> Date: Tue, May 5, 2009 at 7:34 PM
> Subject: FYI: javax.inject* standard ...
> To: openwebbeans-...@incubator.apache.org
> Cc: Pete Muir 
>
>
> FYI:
> http://google-code-updates.blogspot.com/2009/05/javaxinjectinject.html
>
> what does this mean to JSR 299 ?
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: [TRINIDAD] Allow redefinition of the RequestContextFactory

[Simon Lessard]

Yeah PartialPageContextImpl does, I'll try to find the best possible design,
I don't really like moving methods to public API unless they really have to
be there. I'll work on that this weekend most likely, along with some 2.0
tasks.


~ Simon

On Fri, May 1, 2009 at 1:12 PM, Blake Sullivan wrote:

>  Does any of the impl code cast the RequestContext to the
> RequestContextImpl?  If it does, that would be the reason.
>
> -- Blake
>
> Matthias Wessendorf said the following On 5/1/2009 4:06 AM PT:
>
> not sure why it was done. The code was never really touched within the
> last two years..
>
> Perhaps Blake or Andy know ? :)
>
> On Thu, Apr 30, 2009 at 7:33 PM, Simon Lessard 
>  wrote:
>
>
>  Hi,
>
> Currently Trinidad won't allow to redefine the RequestContextFactory once
> it's defined, preventing any attempt to decorate it. Would it be ok with you
> if I removed that check?
>
>
> Regards,
>
> ~ Simon
>
>
>
>
>

[Trinidad][API] Move getPartialTargets() to public API

[Simon Lessard]

Hi,

Along the same line as my previous post, in order to successfully decorate a
RequestContext, public Iterator getPartialTargets() would have to be
graduated from RequestContextImpl to RequestContext in order to remove a
dependency between PartialPageContextImpl and RequestContextImpl. If anyone
see another possibility to achieve the same decoration goal (beside
extending RequestContextImpl directly please), it would be welcome.


Regards,

~ Simon

Re: MyFaces 2.0 question regarding ViewHandler impl

[Simon Lessard]

Hi Michael,

Definitely 3. It's true that JSF 2.0's ViewHandler no longer do much, it
pretty much only deal with HTTP headers and such while most of the work is
delegated to the VDL. 2 might break the TCK I think so it's not a good
option.

~ Simon

On Thu, Apr 30, 2009 at 4:47 PM, Michael Concini  wrote:

> I'm currently looking at updating JspViewhandlerImpl and
> FaceletViewHandlerImpl for MYFACES-2219.  As I'm looking at this, it seems
> that many/most of the methods that need to be implemented or updated will be
> identical for both JSP and Facelet.
> I see three potential ways of handling this:
> 1) Have lots of duplicate code in both impl classes. 2) Implement in the
> API.where possible
> 3) Create an abstract parent class that extends ViewHandler for the impl
> classes to extend from.
> The first option is not ideal for obvious reasons.  With respect to the
> second option, the JSF spec already forces a lot of implementing in the API.
>  I'd rather not add more if possible since its really not the place for it.
>  My preference would be for the third option.  I could push the ViewHandler
> method impls common to both Facelet and JSP to a new class (maybe
> org.apache.myfaces.application.AbstractViewHandler) and then implement the
> method which are different for each in the JSP and Facelet impls
> respectively.
> Thanks for you input,
> Mike
>

Re: [TRINIDAD][API] JIRA-1465 Allow public access to the UIXComponent renderer, if any

[Simon Lessard]

Hi,

I won't -1 it, most likely +0, but I'm curious, why can't
RenderKit.getRenderer be used for that case use case? The only case it does
not cover would be a component not getting its Renderer the standard way,
but to my knowledge all UIXComponent do so I'm not sure.


Regards,

~ Simon

On Thu, Apr 30, 2009 at 1:47 PM, Blake Sullivan
wrote:

> The proposal is to allow public access to the UIXComponent's Renderer, if
> any.
>
> UIComponent only allows protected access to the Renderer, which is normally
> considered an implementation detail of the component. However, because of
> the Component/Renderer split, information is often only available on the
> Renderer and only applicable when that Renderer is present.
>
> /**
>  * Returns the Renderer of this component cast to the specified Renderer
> type or
>  * null if the component's Renderer isn't of the specified
> type.
>  * @param context FacesContext
>  * @param type The Renderer class to return the Renderer as
>  * @return the Renderer of this component cast to the specified Renderer
> type
>  */
> public final  S getRendererAs(FacesContext context,
> Class type)
> {
>  Renderer renderer = getRenderer(context);
>
>  if (type.isInstance(renderer))
>  {
>return type.cast(renderer);
>  }
>  else
>  {
>return null;
>  }
> }
>
> A concrete example of how this api is used is code to handle embedding
> style definitions in an HTML document so that the HTML document can be
> e-mailed and viewed in e-mail readers that don't support external style
> sheets. This is implemented by having the DocumentRenderer walk the
> component tree, asking each component for its Renderer and then asking the
> Renderer what selector it renders when rendering content.
>
> Alternatives would be:
> 1) Exposing a Selector getComponentSelector() on UIXComponent and a similar
> method on CoreRenderer
>
> 2) Creating subclasses of every single UIXComponent class and exposing an
> interface with the method to do the same thing. However this would mean that
> we wouldn't be able to handle the case where a UIXComponent class was used
> with one of our Renderers directly and would also needlessly deepen the
> component hierarchy
>
> -- Blake Sullivan
>
>

[TRINIDAD] Allow redefinition of the RequestContextFactory

[Simon Lessard]

Hi,

Currently Trinidad won't allow to redefine the RequestContextFactory once
it's defined, preventing any attempt to decorate it. Would it be ok with you
if I removed that check?


Regards,

~ Simon

[jira] Commented: (MYFACES-2222) ViewHandler.DEFAULT_SUFFIX could contain several suffixes

[Simon Lessard (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704635#action_12704635
 ] 

Simon Lessard commented on MYFACES-:


I'm not sure if FaceletViewHandler will even continue to exists as the VDL 
deals with more variations between JSP and Facelets, there's no harm adding it 
for now though.

> ViewHandler.DEFAULT_SUFFIX could contain several suffixes
> -
>
> Key: MYFACES-
> URL: https://issues.apache.org/jira/browse/MYFACES-
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Reporter: Leonardo Uribe
>
> Now the value of ViewHandler.DEFAULT_SUFFIX is ".xhtml .jsp"
> All code that depends on this constant should be changed to deal with it 
> (including org.apache.myfaces.view.facelets parts).
> It should change:
> org.apache.myfaces.application.DefaultViewHandlerSupport
> org.apache.myfaces.view.facelets.FaceletViewHandler (getDefaultSuffix method)

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

Re: [COMMUNITY] MyFaces += Ganesh Jung and Alexander Belld

[Simon Lessard]

Congratulations and thanks for the great work on JSF 2.0 AJAX.

On Tue, Apr 28, 2009 at 4:35 AM, Matthias Wessendorf wrote:

> welcome!
>
>
> -- Forwarded message --
> From: Cagatay Civici 
> Date: Tue, Apr 28, 2009 at 10:27 AM
> Subject: Re: [COMMUNITY] MyFaces += Ganesh Jung and Alexander Belld
> To: MyFaces Development 
>
>
> Welcome aboard guys!
>
> On Tue, Apr 28, 2009 at 9:23 AM, Werner Punz 
> wrote:
> >
> > The Myfaces PMC is proud to announce two new additions to our community.
> >
> > Please welcome Alexander Bell and Ganesh Jung as the newest MyFaces
> committer!
> > Alexander and Ganesh are active members of the myfaces community,
> especially in
> > the myfaces 2.0 section of the code
> >
> > @Alex and Ganesh: Please add yourself to the Master-POM at
> >
> https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml
> >
> > -Werner
> >
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: [COMMUNITY] MyFaces += Michael Concini

[Simon Lessard]

Congratulations and thanks for the great work.

On Tue, Apr 28, 2009 at 4:28 AM, Werner Punz  wrote:

> Matthias Wessendorf schrieb:
>
>> The Myfaces PMC is proud to announce a new addition to our community.
>>
>> Please welcome Michael Concini as the newest MyFaces committer!
>> Michael is an active member of the myfaces community, especially in
>> the myfaces 2.0 section of the code
>>
>> @Michael: Please add yourself to the Master-POM at
>> https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml
>>
>> -Matthias
>>
>>  Congratulations
>
> Werner
>
>

Re: [VOTE] MyFaces 2.0 optimization options

[Simon Lessard]

[1] +1
[2] -1
[3] -1
[4] +0

On Fri, Apr 24, 2009 at 9:40 AM, Cagatay Civici wrote:

> [1] +1
> [2] -1
> [3] -1
> [4] +0
>
>
> On Fri, Apr 24, 2009 at 2:32 PM, Werner Punz wrote:
>
>>
>> [1] +1
>> [2] -1
>> [3] -1
>> [4] +1
>>
>> Werner
>>
>>
>>
>> Ganesh schrieb:
>>
>>  Hi,
>>>
>>> We are trying to agree on a way to include the optimization options
>>> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
>>> Javascript with the MyFaces JSF 2.0 implementation.
>>>
>>> We've got 4 different proposed solutions, each has been checked for
>>> technical feasability:
>>>
>>> 1.) extra options packed in a new t:ajax tag and myfaces.ajax.request
>>> 2.) optimization options as attributes of f:ajax
>>> 3.) optimization options within f:attributes nested in f:ajax
>>> 4.) a separate taglibrary with a single tag mf:ajax included with the
>>> core
>>>
>>> Please consider the solutions and vote! See previous mails on this list
>>> with "f:ajax and MyFaces extensions" in the subject for further details.
>>>
>>> Please note:
>>> This vote is "majority approval" with a minimum of three +1 votes. This
>>> is a code modification vote [1], so you can veto a solution with a vote of
>>> -1. Please vote whole numbers. You can give a vote on each of the 4
>>> solutions. E.g. you can vote:
>>>
>>> 1.) +1
>>> 2.) +1
>>> 3.) +0
>>> 4.) -1
>>>
>>> The vote lasts for 72 hours. It start on 2009-04-24 11:45 a.m. and ends
>>> on 2009-04-27 11:45 a.m.
>>>
>>> 
>>> [ ] +1 - you favourize this solution
>>> [ ] +0 - you don't like this solution
>>> [ ] -1  - you veto this solution
>>>
>>>
>>> Best Regards,
>>> Ganesh Jung
>>>
>>> [1] http://www.apache.org/foundation/voting.html <
>>> http://www.apache.org/foundation/voting.html#ReleaseVotes>
>>>
>>>
>>
>

Re: MyFaces 2.0 javascripts are now feature complete

[Simon Lessard]

Awesome, thanks to everyone who helped with that.

Now I gotta do my part and finish Facelets...


~ Simon

On Thu, Apr 23, 2009 at 6:06 AM, Matthias Wessendorf wrote:

> On Thu, Apr 23, 2009 at 11:46 AM, Werner Punz 
> wrote:
> > Hello everyone
> >
> > as it seems, *knock on wood* we are now feature complete in our
> javascripts.
> > Currently you can use the files by a manual include of following files in
> > following order:
> >
> >api/OpenAjax.js
> >_impl/_util/_LangUtils.js
> >_impl/_util/_ListenerQueue.js
> >_impl/_util/_Logger.js
> >_impl/_util/_Utils.js
> >_impl/xhrCore/_Exception.js
> >_impl/xhrCore/_AjaxUtils.js
> >_impl/xhrCore/_AjaxRequestQueue.js
> >_impl/xhrCore/_AjaxRequest.js
> >_impl/xhrCore/_AjaxResponse.js
> >_impl/xhrCore/_xhrCoreAdapter.js
> >_impl/core/jsf_impl.js
> >api/jsf.js
> >
> > Note the build process to generate a single compressed jsf.js has been
> > prepared but not yet been enabled
> > The build process uses currently the standard alpha quality standard
> maven
> > javascript plugin because I could not get our javascript plugin to work
> for
> > now (I would be more than happy if anyone could get ours to run)...
> >
> > Thanks to Alex and Ganesh for the outstanding work.
>
> +1
> Great job guys.
> Was good to see the main development was happening, as it should, here.
>
> Community over code is a big plus! :-)
>
> -Matthias
>
> > So what still has to be done on the javascript side of things.
> > Code cleanup, bugfixing, additional configuration options, and
> integration
> > of spec changes, and documentation...
> >
> > Werner
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Re: Testing archetypes for MyFaces projects?

[Simon Lessard]

Definitely +1

~ Simon

On Tue, Apr 21, 2009 at 3:27 PM, Leonardo Uribe  wrote:

> Hi
>
> Just for information purposes and as start point, what we have right now is
> this wiki page:
>
> http://wiki.apache.org/myfaces/MyFaces_Archetypes_for_Maven
>
> The archetypes available
>
> myfaces-archetype-helloworld // myfaces 1.2 + tomahawk
> myfaces-archetype-helloworld-facelets // myfaces 1.2 + facelets +
> tomahawk
> myfaces-archetype-helloworld-portlets  // myfaces 1.2 + portlet
> bridge
> myfaces-archetype-jsfcomponents   // simple components in the
> old way, the next release will use myfaces builder plugin.
> myfaces-archetype-trinidad  // myfaces 1.2 +
> trinidad
>
> It could be good to know what other archetypes are useful and what other
> wiki pages are needed, to contribute and make another release of this
> project.
>
> regards
>
> Leonardo Uribe
>
>
> On Tue, Apr 21, 2009 at 12:38 PM, Grant Smith wrote:
>
>> +1 !!!
>>
>>
>> On Tue, Apr 21, 2009 at 10:32 AM, Andrew Robinson <
>> andrew.rw.robin...@gmail.com> wrote:
>>
>>> I was wondering if we would want to create maven archetypes for
>>> setting up trinidad, tomahawk, and other projects as a war file that
>>> users can use to start a test case. Basically it would create a war
>>> pom with a single page and a single managed bean with jetty support
>>> built in so that it would be easy to modify to get going.
>>>
>>> By doing this and building a WIKI page we could simply point bug
>>> reporters to the WIKI to give them instructions on how to build a
>>> simple test case that would not be IDE or platform specific and help
>>> with people that want to debug problems, but do not want to try each
>>> time to extract how to reproduce a problem.
>>>
>>> What do you all think?
>>>
>>> -Andrew
>>>
>>
>>
>>
>> --
>> Grant Smith
>>
>>
>

Re: MyFaces 2.0 Ajax Java part

[Simon Lessard]

Hi,

The class gets generated by a Maven plugin using _UISelectItems as a base.
It works fine for me. Did you checkout also the mavin plugin projects?


Regards,

~ Simon

On Sun, Apr 19, 2009 at 4:30 PM, Ganesh  wrote:

> Hi Simon,
>
> I have run mvn install. In the API
> javax.faces.component._SelectItemsIterator contains references to class
> UISelectItems which doesn't exists. There is a class named
> javax.faces.component._UISelectItems and if you wouldn't say it compiles
> fine for you I'd think it's a typo in
> javax.faces.component._SelectItemsIterator. Similar issues exist for
> UIMessage and UIMessages.
>
> Here's a link to the ViewVC of the 2_0_0 branch. I think it supports that
> there is _UISelectItems, but no UISelectItems and that _SelectItemsIterator
> references UISelectItems:
>
>
> http://svn.apache.org/viewvc/myfaces/core/branches/2_0_0/api/src/main/java/javax/faces/component/
>
> Can you please check this again?
>
> Best Regards,
> Ganesh
>
> Simon Lessard schrieb:
>
>  Hi Ganesh,
>>
>> I think you forgot to execute mvn install on the build maybe because it
>> compiles fine for me.
>>
>> As for running the whole thing I don't think it would be working yet since
>> some Lifecycle phases were already modified to use the new Ajax API on
>> partial request, but there's no impl for that code yet. Once the partial
>> context and writer as well as JSP VDL are implemented then I think a simpel
>> test case will be runnable.
>>
>>
>> Regards,
>>
>> ~ Simon
>>
>

Re: MyFaces 2.0 Ajax Java part

[Simon Lessard]

Hi Ganesh,

I think you forgot to execute mvn install on the build maybe because it
compiles fine for me.

As for running the whole thing I don't think it would be working yet since
some Lifecycle phases were already modified to use the new Ajax API on
partial request, but there's no impl for that code yet. Once the partial
context and writer as well as JSP VDL are implemented then I think a simpel
test case will be runnable.


Regards,

~ Simon

On Fri, Apr 17, 2009 at 12:29 AM, Ganesh  wrote:

> Hi Simon,
>
> After we got getting most of the Javascript running I want to switch next
> week to the Java part as there is partial processing within the phases, the
> PartialResponseWriter, the f:ajax tag and some more to be done.
>
> I've checked out the "Apache MyFaces JSF Core-2.0 API" Netbeans project but
> within Netbeans but it shows compile errors. I'm missing classes
> javax.faces.UISelectItems, UIMessage and UIMessages to compile classes
> _SelectItemsIterator, _HtmlMessages and _HtmlMessage. Is this due to the
> uncomplete development or am I missing anything substantial?
>
> How far has the development come? Is it worth starting a maven build and
> trying to run the whole thing? Is there a trivial testcase that is already
> functional?
>
> Best Regards,
> Ganesh
>

Re: MyFaces 2.0 Ajax and a big thank you

[Simon Lessard]

I second that.

~ Simon

On Tue, Apr 14, 2009 at 4:36 AM, Werner Punz  wrote:

> Hello Ganesh and Alex
>
> I have committed the patches into the main MyFaces tree, again a big thank
> you you did a load of work over easter and wow the code now has become
> slim...
>
> Ok here is the additional timetable from my side:
>
> I would work on the response handling again on thursday and friday,
> I cannot do it before since I am bound by company projects as you know from
> monday til wednesday.
>
> What I would do is, to finish the response area on the javascript side and
> then add some mockup tests via a servlet which simulates the response
> according to the spec xml schema do iron out the bugs (especially working
> around the IE bugs in its quirks mode in the setAttributes areae is still an
> untested water by some parts of the code I preworked last week, it should
> work but needs testing on my side!).
>
> I am not sure if I am able to commit the servlet tests into the apache
> codebase since automated tests in this area require selenium which again
> requires x-windows on the unix side for the browser engines as far as I
> know.
>
> After that I will have a look at the java codebase to start with the Ajax
> ResponseWriter, if nothing has been done in the area yet!
>
> If you guys want to work upfront in any area you want feel free...
> I am sure you still have work to do on your specialized listeners or you
> might want to work on the response as well.
>
> I will apply the patches as soon as possible as they crawl up so that you
> guys have an easier life to keep the codebases in sync!
>
> Again thanks for your tremendous help, you definitely have earned a huge
> applause by the rest of the community!
>
>
> Werner
>
>

[jira] Resolved: (MYFACES-2049) Implement tag composite:editableValueHolder

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2049.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag composite:editableValueHolder 
> 
>
> Key: MYFACES-2049
> URL: https://issues.apache.org/jira/browse/MYFACES-2049
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag composite:editableValueHolder for Facelets

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

[jira] Resolved: (MYFACES-2050) Implement tag composite:facet

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2050.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag composite:facet 
> --
>
> Key: MYFACES-2050
> URL: https://issues.apache.org/jira/browse/MYFACES-2050
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag composite:facet  for Facelets

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

[jira] Resolved: (MYFACES-2055) Implement tag composite:valueHolder

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2055.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag composite:valueHolder 
> 
>
> Key: MYFACES-2055
> URL: https://issues.apache.org/jira/browse/MYFACES-2055
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag composite:valueHolder for Facelets

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

[jira] Resolved: (MYFACES-2043) Implement tag c:if

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2043.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag c:if 
> ---
>
> Key: MYFACES-2043
> URL: https://issues.apache.org/jira/browse/MYFACES-2043
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag c:if  for Facelets

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

[jira] Resolved: (MYFACES-2068) Implement tag fn:substringBefore()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2068.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:substringBefore() 
> ---
>
> Key: MYFACES-2068
> URL: https://issues.apache.org/jira/browse/MYFACES-2068
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:substringBefore() for Facelets

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

[jira] Resolved: (MYFACES-2051) Implement tag composite:implementation

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2051.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag composite:implementation
> --
>
> Key: MYFACES-2051
> URL: https://issues.apache.org/jira/browse/MYFACES-2051
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag composite:implementation for Facelets

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

[jira] Resolved: (MYFACES-2069) Implement tag fn:toLowerCase()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2069.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:toLowerCase() 
> ---
>
> Key: MYFACES-2069
> URL: https://issues.apache.org/jira/browse/MYFACES-2069
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:toLowerCase()  for Facelets

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

[jira] Resolved: (MYFACES-2060) Implement tag fn:indexOf()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2060.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:indexOf() 
> ---
>
> Key: MYFACES-2060
> URL: https://issues.apache.org/jira/browse/MYFACES-2060
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:indexOf() for Facelets

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

[jira] Resolved: (MYFACES-2059) Implement tag fn:escapeXml()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2059.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:escapeXml() 
> -
>
> Key: MYFACES-2059
> URL: https://issues.apache.org/jira/browse/MYFACES-2059
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:escapeXml() for Facelets

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

[jira] Resolved: (MYFACES-2071) Implement tag fn:trim()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2071.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:trim() 
> 
>
> Key: MYFACES-2071
> URL: https://issues.apache.org/jira/browse/MYFACES-2071
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:trim() for Facelets

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

[jira] Resolved: (MYFACES-2044) Implement tag c:otherwise

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2044.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag c:otherwise 
> --
>
> Key: MYFACES-2044
> URL: https://issues.apache.org/jira/browse/MYFACES-2044
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag c:otherwise for Facelets

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

[jira] Resolved: (MYFACES-2058) Implement tag fn:endsWith()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2058.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:endsWith() 
> 
>
> Key: MYFACES-2058
> URL: https://issues.apache.org/jira/browse/MYFACES-2058
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:endsWith() for Facelets

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

[jira] Resolved: (MYFACES-2064) Implement tag fn:split()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2064.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:split()
> 
>
> Key: MYFACES-2064
> URL: https://issues.apache.org/jira/browse/MYFACES-2064
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:split() for Facelets

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

[jira] Resolved: (MYFACES-2047) Implement tag composite:actionSource

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2047.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag composite:actionSource 
> -
>
> Key: MYFACES-2047
> URL: https://issues.apache.org/jira/browse/MYFACES-2047
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag composite:actionSource for Facelets

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

[jira] Resolved: (MYFACES-2070) Implement tag fn:toUpperCase()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2070.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:toUpperCase() 
> ---
>
> Key: MYFACES-2070
> URL: https://issues.apache.org/jira/browse/MYFACES-2070
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:toUpperCase()  for Facelets

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

[jira] Resolved: (MYFACES-2063) Implement tag fn:replace()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2063.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:replace() 
> ---
>
> Key: MYFACES-2063
> URL: https://issues.apache.org/jira/browse/MYFACES-2063
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:replace() for Facelets

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

[jira] Resolved: (MYFACES-2066) Implement tag fn:substring()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2066.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:substring() 
> -
>
> Key: MYFACES-2066
> URL: https://issues.apache.org/jira/browse/MYFACES-2066
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:substring() for Facelets

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

[jira] Resolved: (MYFACES-2052) Implement tag composite:insertChildren

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2052.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag composite:insertChildren 
> ---
>
> Key: MYFACES-2052
> URL: https://issues.apache.org/jira/browse/MYFACES-2052
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag composite:insertChildren for Facelets

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

[jira] Resolved: (MYFACES-2057) Implement tag fn:containsIgnoreCase()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2057.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:containsIgnoreCase() 
> --
>
> Key: MYFACES-2057
> URL: https://issues.apache.org/jira/browse/MYFACES-2057
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:containsIgnoreCase() for Facelets

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

[jira] Resolved: (MYFACES-2048) Implement tag composite:attribute

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2048.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag composite:attribute 
> --
>
> Key: MYFACES-2048
> URL: https://issues.apache.org/jira/browse/MYFACES-2048
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag composite:attribute for Facelets

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

[jira] Resolved: (MYFACES-2054) Implement tag composite:interface

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2054.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag composite:interface 
> --
>
> Key: MYFACES-2054
> URL: https://issues.apache.org/jira/browse/MYFACES-2054
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag composite:interface for Facelets

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

[jira] Resolved: (MYFACES-2065) Implement tag fn:startsWith()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2065.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha
 Assignee: Simon Lessard

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:startsWith() 
> --
>
> Key: MYFACES-2065
> URL: https://issues.apache.org/jira/browse/MYFACES-2065
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:startsWith() for Facelets

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

[jira] Resolved: (MYFACES-2045) Implement tag c:set

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2045.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag c:set 
> 
>
> Key: MYFACES-2045
> URL: https://issues.apache.org/jira/browse/MYFACES-2045
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag c:set for Facelets

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

[jira] Resolved: (MYFACES-2061) Implement tag fn:join()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2061.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:join() 
> 
>
> Key: MYFACES-2061
> URL: https://issues.apache.org/jira/browse/MYFACES-2061
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:join() for Facelets

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

[jira] Resolved: (MYFACES-2067) Implement tag fn:substringAfter()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2067.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:substringAfter() 
> --
>
> Key: MYFACES-2067
> URL: https://issues.apache.org/jira/browse/MYFACES-2067
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:substringAfter() for Facelets

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

[jira] Resolved: (MYFACES-2042) Implement tag c:forEach

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2042.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag c:forEach 
> 
>
> Key: MYFACES-2042
> URL: https://issues.apache.org/jira/browse/MYFACES-2042
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag c:forEach  for Facelets

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

[jira] Resolved: (MYFACES-2046) Implement tag c:when

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2046.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag c:when 
> -
>
> Key: MYFACES-2046
> URL: https://issues.apache.org/jira/browse/MYFACES-2046
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag c:when for Facelets

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

[jira] Resolved: (MYFACES-2041) Implement tag c:choose

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2041.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag c:choose 
> ---
>
> Key: MYFACES-2041
> URL: https://issues.apache.org/jira/browse/MYFACES-2041
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag c:choose for Facelets

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

[jira] Resolved: (MYFACES-2053) Implement tag composite:insertFacet

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2053.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag composite:insertFacet  
> -
>
> Key: MYFACES-2053
> URL: https://issues.apache.org/jira/browse/MYFACES-2053
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag composite:insertFacet for Facelets

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

[jira] Resolved: (MYFACES-2056) Implement tag fn:contains()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2056.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:contains() 
> 
>
> Key: MYFACES-2056
> URL: https://issues.apache.org/jira/browse/MYFACES-2056
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Assignee: Simon Lessard
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:contains() for Facelets

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

[jira] Resolved: (MYFACES-2062) Implement tag fn:length()

[Simon Lessard (JIRA)]

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

Simon Lessard resolved MYFACES-2062.


   Resolution: Duplicate
Fix Version/s: 2.0.0-alpha

I'm integrating all Facelets tags tickets into MYFACES-2183 since it's copied 
from original Facelets code so I doubt I'll be forgetting any while integrating.

> Implement tag fn:length() 
> --
>
> Key: MYFACES-2062
> URL: https://issues.apache.org/jira/browse/MYFACES-2062
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Marc De Lafontaine
>Priority: Minor
> Fix For: 2.0.0-alpha
>
>
> Create tag fn:length() for Facelets

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