I'll be starting my JSR-301 work here, so I'll do it some time today...
regards,
Martin
On 10/23/07, Manfred Geiler [EMAIL PROTECTED] wrote:
I can do it on Thursday.
Matthias, if you are able to spend some time earlier, then: please, thanks.
-Manfred
On 10/23/07, Matthias Wessendorf
For me, a merger makes sense.
The question is who will do the work, though.
Some reflections on the modules:
- ViewController/Dialog: I hope Orchestra can take in what makes sense
here (the notion of subflows which
- Clay: Yes, obviously Facelets has won the race - we should all
concentrate our
There has been a discussion on configuration in the view (with
components) some time ago, and some of the JSF experts on this list
argued that one shouldn't use non-visible components in the view (e.g.
Adam, Craig, others).
I actually like the option with annotations best - until we need a
Repost (sent directly to Matthias by accident)
On 10/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
ok, so then, if we'd like to go down that road we should follow the scxml
way if possible.
I am +0 on that as I don't want to be a competitor with spring webflow - at
least I'd
[
https://issues.apache.org/jira/browse/MYFACES-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek resolved MYFACES-1748.
Resolution: Invalid
Assignee: Scott O'Bryan
[
https://issues.apache.org/jira/browse/MYFACES-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537224
]
Martin Marinschek commented on MYFACES-1748:
Can I clarify a little more?
MyFaces is correct here,
Hi all,
nice! the nightly build downloads are up again - the snapshot
repository still doesn't show the new jars, however. How can we fix
this?
regards,
Martin
On 10/21/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 10/21/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Tobago is still using the
enhancing (but not overstuffing, KISS) Orchestra makes sense. No use to
split the libraries further.
- add the subflows
- add the s:token (double posting)
other parts: no preference
regards
Alexander
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Wednesday,
The stream identifier will take into account the FQCN, and the
version-identifier - so the two classes won't have the same stream
identifier, IMHO.
regards,
Martin
On 10/19/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Please consider the consequences of two different classes w/ the same stream
Hi Val,
I was just referring to your code snippet, which didn't show you were
using Tomahawk. So you don't want to change JSF
error-message-handling, but Tomahawk message-handling?
regards,
Martin
On 10/19/07, Val [EMAIL PROTECTED] wrote:
Yes, I am using tomahawk 1.1.2. Specifically, I use
cool
On 10/24/07, Martin Marinschek [EMAIL PROTECTED] wrote:
I'll be starting my JSR-301 work here, so I'll do it some time today...
regards,
Martin
On 10/23/07, Manfred Geiler [EMAIL PROTECTED] wrote:
I can do it on Thursday.
Matthias, if you are able to spend some time earlier, then:
Done! Thanks! I have put your class in the sources.
If you, or anyone else for that matters, want to fix /add more
handlers to the projects feel free to tell me and I can add you as
members right away!
Thanks,
Bruno
On 23/10/2007, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Please consider
[
https://issues.apache.org/jira/browse/TRINIDAD-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf updated TRINIDAD-771:
Resolution: Fixed
Fix Version/s: 1.2.3-core
Status: Resolved
Datepicker does not render time-component when associated to Timestamp
--
Key: TOBAGO-520
URL: https://issues.apache.org/jira/browse/TOBAGO-520
Project: MyFaces Tobago
Hi!
In JSF 1.1 I am curious about the javax.faces.renderer.Renderer class in
JSF 1.1, in particular the following piece of code:
public void encodeChildren(FacesContext context,
UIComponent component)
throws IOException
{
if (context ==
[
https://issues.apache.org/jira/browse/MYFACES-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537272
]
Stefan Rinke commented on MYFACES-1750:
---
I've developed a workaround / bugfix for the related class
[
https://issues.apache.org/jira/browse/MYFACES-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Rinke updated MYFACES-1750:
--
Status: Patch Available (was: Open)
Evaluation of EL-Expression fails with custom
Hi,
as to why does it work, the answer should be simple - almost all
renderers in MyFaces do ALL encoding work in encodeEnd method
(including rendering children).
But what do i wonder more is why page's component tree contains ALL
previously rendered/encoded components.
Wouldn't it make
Hi,
regarding TOMAHAWK-1115 ([1]), do we want to support it inside of
Tomahawk, or the sandbox ?
-Matthias
[1] https://issues.apache.org/jira/browse/TOMAHAWK-1115
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
[
https://issues.apache.org/jira/browse/TRINIDAD-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf resolved TRINIDAD-131.
-
Resolution: Invalid
not a bug...
required inputFile (re-submitted) causes
Hi Bruno
I have put your class in the sources.
Thanks!
Unfortunately I don't know what I've done yesterday to not see a bug
with my TagHandler.
Please add this line this.nextHandler.apply(ctx, aliasBean); at the
end of the apply method, so it should look like the following then:
{
Hi!
If you, or anyone else for that matters, want to fix /add more
handlers to the projects feel free to tell me and I can add you as
members right away!
What about a MyFaces Facelets (MyFaces MyFacelets ;-) ) project at all,
not only for the taglibs we might host there then (as long as the
Hi Mario,
if getRendersChildren() returns fals, the JSP-tag will call encodeChildren().
regards,
Martin
On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
In JSF 1.1 I am curious about the javax.faces.renderer.Renderer class in
JSF 1.1, in particular the following piece of code:
some one konw, how is going, will be tomahawk 1.2?
On 10/23/07, Werner Punz [EMAIL PROTECTED] wrote:
Dennis Byrne schrieb:
Caucho claims to have implemented and released JSF 2.0 [1] before the
spec was finished!
huh, I thought they dont even have a fully working jee5 spec ;-)
I assume
Hi!
if getRendersChildren() returns fals, the JSP-tag will call encodeChildren().
I still wonder how the mixing of rendersChildren true/false/true/false
is going to work, but I've seen the code in JSF1.1 is much easier so I
am not going to spend any more time on this topic.
Thanks!
Ciao,
Sochor Zdeněk [EMAIL PROTECTED] schrieb:
Hi,
as to why does it work, the answer should be simple - almost all
renderers in MyFaces do ALL encoding work in encodeEnd method
(including rendering children).
To be more specific (he says, after some hurried study of the code):
Normally
Hi Mario, Simon,
indeed, this is a bug - I just looked at the Renderer source-code more
carefully. Funny thing is - I thought I had fixed this bug once, and
now, there it is again. Maybe I fixed it at some other place.
regards,
Martin
On 10/24/07, Simon Kitching [EMAIL PROTECTED] wrote:
encodeChildren in Renderer-base-class is wrongly implemented
Key: MYFACES-1751
URL: https://issues.apache.org/jira/browse/MYFACES-1751
Project: MyFaces Core
Issue Type: Bug
[
https://issues.apache.org/jira/browse/MYFACES-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek resolved MYFACES-1751.
Resolution: Fixed
encodeChildren in Renderer-base-class is wrongly implemented
Hi Simon,
comments inside.
Simon Kitching napsal(a):
Sochor Zdeněk [EMAIL PROTECTED] schrieb:
Hi,
as to why does it work, the answer should be simple - almost all
renderers in MyFaces do ALL encoding work in encodeEnd method
(including rendering children).
To be more
Once I get back to JSF work, I'd happily contribute to a MyFaces
Facelets project. As I've said in years past, I don't know how to
set up a maven project, but once someone set up the infrastructure for
such a project, I'd be able to help with the rest.
The same goes for the MyFaces commons
Yes, wouldn't that have to be the case? Otherwise, A.jar and B.jar,
created by two independent groups, might use the same version id
without realizing it, and thus break a project depending on both of
them.
On 10/24/07, Martin Marinschek [EMAIL PROTECTED] wrote:
The stream identifier will
Hi!
Lets start up the long awaited MyFaces Commons project.
The aim of this project will be to contain all stuff which do not belong
to a component.
[ ] +1 yea, lets start
[ ] +0
[ ] -1 no, for those reasons .
I'll do the maven work then (a not very sophisticated one, just copy it
from
+1
:-)
On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Lets start up the long awaited MyFaces Commons project.
The aim of this project will be to contain all stuff which do not belong
to a component.
[ ] +1 yea, lets start
[ ] +0
[ ] -1 no, for those reasons .
I'll do
[
https://issues.apache.org/jira/browse/TRINIDAD-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Starets reopened TRINIDAD-737:
--
Reopening this issue since the fix was reverted as a result of TRINIDAD-771
Need To Establish
Actually, let's clarify this to be all the stuff which is not
renderkit-specific.
Ie, if the validator/component/converter/other can be used with any
reasonable[1] combination of
JSF_RI/MyFacesCore/Tomahawk/Tobago/Trinidad/IceFaces/RichFaces/PortletBridge,
then it should be available here.
[1]
Hi!
Lets start up a MyFaces Facelets project. A name needs to be found.
The aim of this project will be to contain:
1) the taglibs for tomahawk and tomahawk-sandbox as long as we have the
generator not running again. I'd like to ask Bruno if we can jump-start with
his google project
2)
+1.
I'd suggest tomahawk-facelets[.jar] as the name since that's what it
is. The versioning should match Tomahawk's versioning, and hopefully
we'll release a new version each time Tomahawk is released.
On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Lets start up a MyFaces
Exactly - that's for sure. If it wasn't like that, Eclipse wouldn't
use 1 as a default version id. If it was like Dennis suggested, every
app built with Eclipse would go kaboom.
;)
regards,
Martin
On 10/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Yes, wouldn't that have to be the case?
Mario,
In general agree with the need for a commons project. Before voting, I
need some more information:
1) Will their be a JSF version specific version, i.e. commons_1.2 and
commons_2.0?
2) What are some of the module will you be moving into the project(s)?
Paul Spencer
Mario
ja, same here
+1
On 10/24/07, Martin Marinschek [EMAIL PROTECTED] wrote:
ok, sounds good.
+1 for both suggestions.
regards,
Martin
On 10/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Actually, let's clarify this to be all the stuff which is not
renderkit-specific.
Ie, if the
t:dataTable does not seems to be supporting java.sql.ResultSet. It works fine
with h:dataTable
---
Key: TOMAHAWK-1134
URL:
Done! Thanks Mario :)
Bruno
On 24/10/2007, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi Bruno
I have put your class in the sources.
Thanks!
Unfortunately I don't know what I've done yesterday to not see a bug
with my TagHandler.
Please add this line this.nextHandler.apply(ctx,
Also, just to clarify for those who haven't waded through the past
archives on the subject, this is mostly a structural change rather
than an organizational change.
The goal is to split the Tomahawk jars into renderkit-specific and
non-renderkit-specific jar files so that Tobago, Seam, and other
On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
1) Will their be a JSF version specific version, i.e. commons_1.2 and
commons_2.0?
H I don't think so, at least for the start not. Lets start
another module once we cross that bridge.
I think, this is a valid question.
Moving this out of the vote thread.
On 10/24/07, Paul Spencer [EMAIL PROTECTED] wrote:
1) Will their be a JSF version specific version, i.e. commons_1.2 and
commons_2.0?
I'd say yes, if it makes sense to do so.
2) What are some of the module will you be moving into the project(s)?
Some of
ok, sounds good.
+1 for both suggestions.
regards,
Martin
On 10/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Actually, let's clarify this to be all the stuff which is not
renderkit-specific.
Ie, if the validator/component/converter/other can be used with any
reasonable[1] combination
Hi!
1) Will their be a JSF version specific version, i.e. commons_1.2 and
commons_2.0?
H I don't think so, at least for the start not. Lets start
another module once we cross that bridge.
2) What are some of the module will you be moving into the project(s)?
Some stuff from the
I've read through my posts here and I think there might be some
miscommunication.
Dennis Byrne
On 10/24/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Exactly - that's for sure. If it wasn't like that, Eclipse wouldn't
use 1 as a default version id. If it was like Dennis suggested, every
app
Hello
When i tried to use tr:tree component, i received some javascript error, and
after checking rendered heml code i have found such inclusion
_addJSL(/247/forward/global/adf/jsLibs/Common1_0_3.js)
And i was surprised that trinidad doesn't contain it.
It contains a big amount of another
Sochor Zdeněk [EMAIL PROTECTED] schrieb:
Hi Simon,
comments inside.
Thanks. When you do that, please also remove the irrelevant bits from the email
(as has been done here)..
But what do i wonder more is why page's component tree contains ALL
previously rendered/encoded
Hi,
+1
although the thing from tomahawk i was missing most, aliasBean, did
not fit into tobagos layout system.
But things like converters and validators should work with any implementation.
Regards,
Volker
2007/10/24, Mario Ivankovits [EMAIL PROTECTED]:
Hi!
Lets start up the long
Hi, Martin.
The change I am proposing is completely independent from Tomahawk. Since
the message decoration happens in the wrapper converter/validator, we
get to decorate any JSF message with or without Tomahawk. In fact, this
should work with any bare JSF implementation and it supersedes
Why wouldn't aliasBean work as a commons project component? I
haven't looked at the implementation, but at first glance of the docs,
it doesn't seem to do anything renderkit-specific. I looked at the
renderer implementation and it simply looks like its being used as a
callback hook back into
I would be a proponent for a new tomahawk-like project to house
facelets-only projects (tag handlers and components). I could even
move my annotation deployment code from jsf-comp over to myfaces for
such a project.
I'd be willing to help setup the projects to use the trinidad maven
plugin for
Hi!
Why wouldn't aliasBean work as a commons project component? I
haven't looked at the implementation, but at first glance of the docs,
it doesn't seem to do anything renderkit-specific.
I think their problem is that you can use the aliasBeansScope (for
example) to group components
+1 non-binding
Gary
-- Original message --
From: Mario Ivankovits [EMAIL PROTECTED]
Hi!
Lets start up the long awaited MyFaces Commons project.
The aim of this project will be to contain all stuff which do not belong
to a component.
[ ] +1 yea, lets
+1 on a facelets-only JSF project and not be related to tomahawk at all.
-1 for #1 I think tomahawk should have built in facelets support for
its own components and not have to rely on an outside project/jar
-1 on using tomahawk in the name (for above reason)
(non-binding)
On 10/24/07, Mike
Hi Mike,
in general i'm +1 for aliasBean into the commons project, it just did
not fit into
tobago.
But there is a problem: afaik aliasBean did not work with RI.
The myfaces lifecycleImpl has a special handling of BindingAware
interface components, which are afaik only aliasBean and
It would definitely be a Tomahawk thing rather than a MyFaces Core change.
I haven't looked at your architecture in detail, but trying to wrap a
validator or converter is problematic, at least under JSF 1.1 + jsp.
It will probably work for JSF 1.2 or JSF 1.1 with facelets, though, if
I remember
Well, if aliasBean only works with Myfaces Core, I wonder why we even
include it with Tomahawk. It sounds like it should really be an
extension point of MyFaces Core.
In any case, it doesn't sound like a candidate for MyFaces commons at present.
On 10/24/07, Volker Weber [EMAIL PROTECTED]
Andrew, you're asking for a different project than what's being proposed.
This is a (hopefully) temporary project to provide drop-in Tomahawk
facelets support until such time as built-in facelets support (via
code generation) is available in Tomahawk.
On 10/24/07, Andrew Robinson [EMAIL
Hi!
This is a (hopefully) temporary project to provide drop-in Tomahawk
facelets support until such time as built-in facelets support (via
code generation) is available in Tomahawk.
Not a temporary project, just a temporary place.
I think (hope) our Facelets project will grow in the future
At the moment I am stuck with JSF 1.1. This is due in part to the
version of Java available on some HP-UX servers. Although I would like
to move to JSF 1.2, this will not occur in the near future. If this is
a common situation, then I suggest JSF 1.1 AND JSF 1.2 should be
current relative
Hi,
i think i should recheck using aliasBean in tobago, if i remember
correct it works as a container component and the alias is valid for
all children. It should be possible in tobago having a extra container
around a component.
Regards,
Volker
2007/10/24, Mario Ivankovits [EMAIL
Alias-Bean works with RI as well, but not if you use component bindings.
The problem why it doesn't work is an ommission in the spec - bindings
are restored out of the JSF-request-lifecycle, outside of a tree
iteration. I have (a long time ago) filed a bug against the spec with
regards to this -
Duplicate error messages shown for inline c/s and server validation
---
Key: TRINIDAD-783
URL: https://issues.apache.org/jira/browse/TRINIDAD-783
Project: MyFaces Trinidad
yes I understand, that is why I mentioned a -1 for a tomahawk based
facelets project. I don't feel the need for a separate project,
putting facelet support into the tomahawk project should be adequate
IMO. It is just that no one has taken the initiative to actually do
the work.
-Andrew
On
This has been brought up in the past (1.2 trunk), but it is again a
hot topic here at oracle for applying trinidad patches.
Currently we have in SVN:
https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad
https://svn.apache.org/repos/asf/myfaces/trinidad/branches/1.2.x-branch
The
[
https://issues.apache.org/jira/browse/TRINIDAD-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537359
]
Matt Cooper commented on TRINIDAD-666:
--
Note regarding Scott's comment about not being able to go into 1.2.3,
I like the idea of have two trunks.
My only concern is that, these two live different lifes :)
I can see that some only maintain 1.2x and some only 1.0x
Perhaps setting a committer rule, to port patch to other branch, WHEN ! these
patches aren't specific to a particular version (like JSF 1.2 -
Indeed the serialVersionUID is used to distinguish between two versions
of the same class. And simply put, it's a performance enhancement. If
serialVersionUID is not present, Java will calculate one based on the
hash (I think). The thing is that needing to calculate a hash each
time a class
non-binding:
+1 on a facelets-related sub-project
-1 on it being only a haven for the tomahawk-taglib (that should be
included
in the tomahawk-jar itself
name-proposal:
I like the MyFacelets from the other thread
regards
Alexander
-Original Message-
From: Mario Ivankovits
I misread Mario's original scope for this proposal. I don't have any
issues with it being more inclusive than tomahawk taglibs. My
apologies to Andrew.
If you are one of the people voting against a facelets subproject
containing tomahawk taglibs, does this mean you are volunteering to
Hi!
MyFacelets is a cute name, but it's going to be confusing and slow to
read. Human brains work on pattern matching, and MyFacelets matches
too closely to other names in the domain (MyFaces/Facelets). Aend iff
youuu donnt thynk tahts turrue, yooo porabably kant reed thhis.
MyFaces MyFaces
On 10/24/07, Val [EMAIL PROTECTED] wrote:
I handled the addition of a converter or validators into the wrapper by
having my custom tag push a dummy UIInput tag onto the tag stack that
UIComponentTag uses and then having the wrapped converter/validators set
themselves up in the dummy component
[
https://issues.apache.org/jira/browse/TOMAHAWK-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Brainard updated TOMAHAWK-1087:
-
datatable dont renders a detail correct if a UIColumns is used
Hi,
I was running the needed tasks to get the 1.2.3 release of the Apache
MyFaces Trinidad CORE out. The artifacts are deployed to my private
Apache account ([1]).
Please take a look at the 1.2.3 artifacts and vote
[ ] +1 for community members
[
https://issues.apache.org/jira/browse/TOMAHAWK-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537417
]
Piotr Steininger commented on TOMAHAWK-777:
---
Was this fix committed? I have this problem in an
[x] +1 for community members who have reviewed the bits
Thank you Matthias
On 10/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
I was running the needed tasks to get the 1.2.3 release of the Apache
MyFaces Trinidad CORE out. The artifacts are deployed to my private
Apache account
Well, it's been two-and-a-half years, but I seem to remember the
problem was that under JSF 1.1 + jsp, the converters and validators
are created from scratch every request rather than restored using the
JSF state-saving mechanism. So all of the values set on the
converters/validators would
I believe we aggregate individual js files in dir below into the common
js file at runtime.
trinidad\trinidad\trinidad-impl\src\main\javascript\META-INF\adf\jsLibs
Don't remember how this happens exactly
Thanks,
Gabrielle
ridex wrote:
Hello
When i tried to use tr:tree component, i
hi, in recent time, i needed, that the error message of the component was
more explicit, i thing that will good, that was a html-popup or alert
javascript, with the mesagge and the focus in the first elemnt with the
problem, also the style of the component change. i wait that this are the
theme of
On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Repost (sent directly to Matthias by accident)
On 10/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
ok, so then, if we'd like to go down that road we should follow the scxml
way if possible.
I am +0 on that as I don't want
Yes, but your wrapping validator doesn't have the ability to save the
state of the wrapped validator, does it? Sorry. I really don't
remember the details, but I would expect Myfaces 1.1.x to still have
the same problem. Perhaps we were just doing it wrong back then,
though :-)
The process
Yes, but your wrapping validator doesn't have the ability to save the
state of the wrapped validator, does it?
All I needed to do here was make my wrapping validator a StateHolder and
call saveAttachedState() on the wrapped validators. So everything is
saved and restored properly this way.
[
https://issues.apache.org/jira/browse/TRINIDAD-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537462
]
Yee-Wah Lee commented on TRINIDAD-748:
--
Proposal : Send down min, max as Strings instead of millisecond
Maven Apt Plugin should support maxmem and meminitial when fork=true
Key: TOBAGO-521
URL: https://issues.apache.org/jira/browse/TOBAGO-521
Project: MyFaces Tobago
Issue
old tags like htmlTag throws NPE
--
Key: MYFACES-1752
URL: https://issues.apache.org/jira/browse/MYFACES-1752
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Mario
yes, gab is right.
the file is created during rt.
depending on a web.xml ctx-param it uses a debugable version or not
(for performance).
the core-renderkit uses ResourceLoaders for that...
Are you a asking because of an issue with 1.0.3 ?
Perhaps you have to clear the cache, sometimes browser
90 matches
Mail list logo
