Hi Blake,
+1 on this cool enhancement!
-Matthias
On Fri, Jul 16, 2010 at 7:16 AM, Blake Sullivan
blake.sulli...@oracle.com wrote:
For Trinidad-1856, I would like to add the following public apis:
New apis:
on org.apache.myfaces.trinidad.bean.util.StateUtils:
/**
* Returns codetrue/code
+1 on this
On Sat, Jul 17, 2010 at 12:16 AM, Blake Sullivan
blake.sulli...@oracle.com wrote:
We currently have scopes for:
Application
Session
PageFlow
View
I propose that we add a Map associated with each window or tab that the user
is interacting with. This would slop into the scope
On Mon, Jul 19, 2010 at 10:01 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi blake,
no - my suggestion was that it should be a feature which can be used
independently.
if users need a window scope and they use
* cdi, they can use codi
* spring, they can use orchestra (if we
Hi guys,
generally I'd like to see this in Trinidad for reasons as stated earlier.
few more comments inline:
On Wed, Jul 21, 2010 at 4:52 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi blake,
@events:
libs like codi might benefit from such additional events. we could think
about
Hi guys,
right now for this feature, I think a close integration to Trinidad
does make sense,
since we already have window handling, including lifecycle and an
(complete) event system.
Hence the proposed API is just a small addition.
certainly this makes sense from your current point of
Hi Matthias,
Not everybody is using CDI and/or Spring.
well, in the real world and a little while in the future, there is not
many people who will not have one of these frameworks in their
applications.
I think, on long term we may want one clean and independent API, where
all these projects
Hi guys,
I didn´t follow this in absolute detail anymore right now, but:
I do not think we should think about serializing MethodExpressions or
ValueExpressions - IMHO, MethodExpressions or ValueExpressions should
never be part of the partial state, cause a user will never change
them
i agree with martin.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/21 Martin Marinschek mmarinsc...@apache.org
Hi Matthias,
Not everybody is using CDI and/or
On Wed, Jul 21, 2010 at 9:44 AM, Martin Marinschek
mmarinsc...@apache.org wrote:
Hi Matthias,
Not everybody is using CDI and/or Spring.
well, in the real world and a little while in the future, there is not
many people who will not have one of these frameworks in their
applications.
I
Hi Jeanne,
My colleague that created the Casablanca skin didn't know about the icon and
style naming convention. Should I change the names of the selectors? Or
should I wait until you decide whether you create a new @icon rule.
Regards,
Marius
On Wed, Jul 21, 2010 at 4:52 AM, Jeanne Waldman
Hmm difficult topic.
Please allow me a few questions:
a.) Trinidad components would still work with using either Orchestra
conversations or CODI?
b) You are not relying on other components or the users using your conversation
stuff if they don't like?
c) if the user doesn't make use of this
hi mark,
nobody said that it would harm (at least i'm not aware of technical issues).
(maybe some people would use it even though they shouldn't - e.g. because
they have an alternative which should be used in their application/s.)
furthermore, i agree with martin - most projects are using (or
On Wed, Jul 21, 2010 at 2:02 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi mark,
nobody said that it would harm (at least i'm not aware of technical issues).
(maybe some people would use it even though they shouldn't - e.g. because
they have an alternative which should be used in
Hi Martin,
On Tue, Jul 20, 2010 at 6:03 PM, Martin Marinschek
mmarinsc...@apache.orgwrote:
For me, the UIData and UIRepeat need to descend from the same
component - and this is actually something which is being discussed on
the EG right now.
-- Right now, UIRepeat does not have the partial
Hi Marius
-- Full state saving means setting the context parameter
javax.faces.PARTIAL_STATE_SAVING to false. This is all, right? I've noticed
that just by doing this, the xhtml pages don't work anymore...only the
jsp-s. There is no state saved in xhtml-s. Am I missing something?
Oh my.
hi,
an optional trinidad-support module for codi, orchestra,... could use the
special events of trinidad. - these trinidad-support modules would have a
dependency to trinidad (and not the other way round). if users don't use the
support module for trinidad, the std. behavior of these frameworks
Hi Mark,
In the JSF 2.0 spec section 5.2.6, the implemented order is defined, thus we
cannot change this.
If you want to overwrite it without changing MyFaces core you could create
your own ELResolverBuilder and set it in ApplicationImpl via
setResolverBuilderForFaces().
However IMO this is a
On Wed, Jul 21, 2010 at 2:51 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi,
an optional trinidad-support module for codi, orchestra,... could use the
special events of trinidad. - these trinidad-support modules would have a
dependency to trinidad (and not the other way round). if
Hello,
As I see, in JspStateManagerImpl.saveSerializedView (actually in the
isWritingState() method), there is a check whether the
JSP_IS_WRITING_STATE_ATTR is set in the FacesContext. But this attribute is
set in ViewHandlerImpl.setWritingState() if there is no StateWriter defined
(if the
imo we should analyze which modules would make sense as stand-alone modules.
if there are 2+ of them, we should really think about such a modularization.
we might get new users who just use some of the stand-alone modules instead
of using something completely different (e.g. because they don't
Hi Martin,
On Wed, Jul 21, 2010 at 10:58 AM, Martin Marinschek
mmarinsc...@apache.orgwrote:
Hi guys,
I didn´t follow this in absolute detail anymore right now, but:
I do not think we should think about serializing MethodExpressions or
ValueExpressions - IMHO, MethodExpressions or
On Wed, Jul 21, 2010 at 3:32 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
imo we should analyze which modules would make sense as stand-alone modules.
if there are 2+ of them, we should really think about such a modularization.
we might get new users who just use some of the
as intermediate solution we could introduce an optional comparator (+
web.xml context-param).
- you can move external el-resolvers e.g. to the end of the list.
advantages:
- users don't have to call a method which is specific to myfaces-core.
- if users switch between myfaces-core and mojarra,
Hi Marius,
-- Take for instance MethodExpressionActionListener. This is an example
where a MethodExpression is part of the state.
then this should (and needs to be changed), right?
Additionally, ValueExpression and MethodExpression are not implemented
by us, so how can you implement
Hi Marius,
ok, Leonardo will hopefully take a look - for you to continue: just
post the partial state values for typical pages right now (you can
also take the pages of the sample as a base if you want).
best regards,
Martin
On Wed, Jul 21, 2010 at 3:23 PM, Marius Petoi
On Jul 20, 2010, at 7:52 PM, Gerhard Petracek wrote:
hi blake,
@events:
libs like codi might benefit from such additional events. we could think
about a trinidad-support module.
Sure
@trinidad window map:
i'm still not convinced. i would use a scope provided by libs like orchestra,
validateBean and java.lang.InstantiationException:
org.apache.myfaces.extensions.validator.beanval.interceptor.BeanValidatorWrapper
---
Key: EXTVAL-108
[
https://issues.apache.org/jira/browse/EXTVAL-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved EXTVAL-108.
-
Fix Version/s: 2.0.4-SNAPSHOT
Resolution: Fixed
validateBean and
Classpath - improve speed up to 1000 times
--
Key: MYFACES-2833
URL: https://issues.apache.org/jira/browse/MYFACES-2833
Project: MyFaces Core
Issue Type: Improvement
Components: General
[
https://issues.apache.org/jira/browse/MYFACES-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michał Kudła updated MYFACES-2833:
--
Status: Patch Available (was: Open)
Classpath - improve speed up to 1000 times
hi tobias,
ok - you mean a plugin for mab which generates pom files (and not a plugin
for maven).
- +1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/21 Tobіas Ullrіch
+1
Am 20.07.10 23:09, schrieb Michael Freedman:
Please vote on the proposed release of MyFaces Portlet Bridge
2.0.0-beta. This is the beta version of the JSR 329 RI: Portlet 2.0
Bridge for JavaServer Faces 1.2. It corresponds to that JSRs Public
Review draft which is currently posted and
Hi Marius, Martin
Yes, it is a bug. The problem is related to some changes done on
MYFACES-2754. I think that this changes was tested against jsp but not
against facelets. I reverted the changes so you can test now.
regards,
Leonardo Uribe
2010/7/21 Martin Marinschek mmarinsc...@apache.org
[
https://issues.apache.org/jira/browse/MYFACES-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe reopened MYFACES-2754:
-
The changes done in this patch causes full state saving fails. When it is used
server
hi blake,
@trinidad window map cdi:
we are just interested in some special events like a page-refresh (triggered
by the user).
everything else is handled internally. - (currently) i don't see a reason
for using such an external map.
@stand-alone trinidad window map:
do you mean there are some
Hi Marius
It seems the optimization for ValueExpression / MethodExpression or
ValueBinding / MethodBinding
is not worth. The test data you provided shows a small improvement, but it
does not take into
account PartialStateHolder instances needs to be wrapped before save, so in
the end the
-1 for having a duplicate functionality.
+1 for using CODI for the @WidnowScoped.
On Wed, Jul 21, 2010 at 8:05 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi blake,
@trinidad window map cdi:
we are just interested in some special events like a page-refresh
(triggered by the
IMHO, Having a duplicate functionality implemented in both CODI and Trinidad
is *not* a motivating thing for the users to upgrade the current working
Trinidad version BUT it will be a painful thing to maintain on both
projects. And for myself as an Apache MyFaces user, It is nice to see
projects
Hazem,
Where is the duplication of functionality? We are talking about an api. As
for the implementation, we can make it pluggable, though in fact, it already
is. If someone wants a WindowManager implementation that uses the Orchestra
scheme for identifying windows, they can do so.
--
Hazem,
I'm still not sure what part you think Trinidad and CODI are duplicating?
Trinidad defines a WindowManager and Window objects and contracts for their
behavior. A WindowManager implementation may have interesting code for
identifying windows and defining the lifecycle. CODI has
Blake,
What is the complexity of moving this functionality to CODI as a Trinidad
extensions on the CODI land?
On Wed, Jul 21, 2010 at 10:37 PM, Blake Sullivan
blake.sulli...@oracle.comwrote:
Hazem,
I'm still not sure what part you think Trinidad and CODI are duplicating?
Trinidad defines a
hi blake,
basically you can use an external map in cdi context implementations.
however, with cdi you shouldn't do that. everybody could just change or
clear it and you would bypass important mechanisms of cdi. i would vote -1
for such an approach. if you plan that trinidad hosts an own window
imo we don't really need to move it. it would be enough to introduce events
which get triggered by trinidad.
in a trinidad support module we could process these special events and
trigger the right parts of codi.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting,
+1
On 7/20/2010 2:09 PM, Michael Freedman wrote:
Please vote on the proposed release of MyFaces Portlet Bridge
2.0.0-beta. This is the beta version of the JSR 329 RI: Portlet 2.0
Bridge for JavaServer Faces 1.2. It corresponds to that JSRs Public
Review draft which is currently posted and
+1
On Wed, Jul 21, 2010 at 11:09 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
imo we don't really need to move it. it would be enough to introduce events
which get triggered by trinidad.
in a trinidad support module we could process these special events and
trigger the right parts
+1
On Wed, Jul 21, 2010 at 11:00 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi blake,
basically you can use an external map in cdi context implementations.
however, with cdi you shouldn't do that. everybody could just change or
clear it and you would bypass important mechanisms
On Jul 21, 2010 9:29 PM, Blake Sullivan blake.sulli...@oracle.com
wrote:
Hazem,
Where is the duplication of functionality? We are talking about an api. As
for the implementation, we can make it pluggable, though in fact, it already
is.
I don't understand this too.
If someone wants a
On Jul 21, 2010, at 1:00 PM, Gerhard Petracek wrote:
hi blake,
basically you can use an external map in cdi context implementations.
however, with cdi you shouldn't do that. everybody could just change or
clear it and you would bypass important mechanisms of cdi.
That's assuming that the
Hazem
On Wed, Jul 21, 2010 at 9:27 PM, Hazem Saleh haz...@apache.org wrote:
IMHO, Having a duplicate functionality implemented in both CODI and Trinidad
is *not* a motivating thing for the users to upgrade the current working
Trinidad version
why? So if Trinidad adds a new dependency for just
Hazem,
On Wed, Jul 21, 2010 at 9:57 PM, Hazem Saleh haz...@apache.org wrote:
Blake,
What is the complexity of moving this functionality to CODI as a Trinidad
extensions on the CODI land?
why do we have to introduce a new set of dependency, to just increase
an existing feature?
IMO it's
On Wed, Jul 21, 2010 at 10:00 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi blake,
basically you can use an external map in cdi context implementations.
however, with cdi you shouldn't do that. everybody could just change or
clear it and you would bypass important mechanisms of
imo martin summarized the objection perfectly [1].
regards,
gerhard
[1] http://www.mail-archive.com/dev@myfaces.apache.org/msg47448.html
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/21
On Wed, Jul 21, 2010 at 10:09 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
imo we don't really need to move it.
Thank you! :)
it would be enough to introduce events
which get triggered by trinidad.
in a trinidad support module we could process these special events and
trigger the
But still it is stupid to now stick in CDI and replace our
pageFlowScope (exists since every) and overhaul our Window/Event
system with it.
I said before that we can have modules for that:
* CODI-Trinidad-PageFlow
* CODI-Trinidad-WindowManager
both could be sub-modules under an umbrella trinidad
Yes, relying on a naming convention and then allowing them to easily
break it without any warning was not so smart.
If you can change it, that would be great since the code goes through
extra cycles trying to figure this out, so if nothing else it will
slightly help performance. If you think
hi matthias,
We are just polishing an exiting feature.
i know - the question was: do we really need such new features/apis?
imo it's time to move forward and use the right tools (again see [1]).
using such a map for trinidad internals is ok. but it feels like a
workaround if users start using
dataScroller does not scroll when dataTable uses alias bean
---
Key: TOMAHAWK-1528
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1528
Project: MyFaces Tomahawk
Issue Type: Bug
Hi all,
I fixed some of the problems (like the NPE in DnD components) and updated
dependencies to use latest MyFaces Core and subprojects.
Here is the new snapshot :
http://wiki.apache.org/myfaces/GSoC2010_HTML5?action=AttachFiledo=viewtarget=myfaces-html5-comp-lib-0.0.2-SNAPSHOT.zip
Cheers,
Ali
[
https://issues.apache.org/jira/browse/TRINIDAD-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabrielle Crawford updated TRINIDAD-1859:
-
Status: Resolved (was: Patch Available)
Fix Version/s:
[
https://issues.apache.org/jira/browse/MYFACES-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2834.
-
Fix Version/s: 2.0.2-SNAPSHOT
Resolution: Fixed
Add myfaces-impl test jar to
Add myfaces-impl test jar to maven repo
---
Key: MYFACES-2834
URL: https://issues.apache.org/jira/browse/MYFACES-2834
Project: MyFaces Core
Issue Type: Improvement
Components: build process
The MyFaces PMC is proud to announce a new addition to our community.
Please welcome Rudy De Busscher as the newest MyFaces committer!
Rudy is an active member of the MyFaces community, especially in
the MyFaces Extensions Validator section of the code.
@Rudy: Please add yourself to the
62 matches
Mail list logo
