may be I don't get it correctly, but a good solution should cover both multi-part form and lifecycle concepts.On 10/12/06, Scott O'Bryan
[EMAIL PROTECTED] wrote:Arash,Is this the multi-part form ExternalContext or the much simplified
pre/post lifecycle stuff?ScottArash Rajaeeyan wrote: thank you
Tree2 doesn't consume value bindings by boolean attributes
--
Key: TOMAHAWK-736
URL: http://issues.apache.org/jira/browse/TOMAHAWK-736
Project: MyFaces Tomahawk
Issue Type: Bug
Isn't that the risk of using components of the sandbox? IMHO, sandbox
components should always be subject to change without notice. If they
are promoted to 'production quality', then so much the better.
Therefore, my personal preference would be to remove all references in
the sandbox after the
OncLick attribute needed fo DIV (or HTMLTag)
Key: TOMAHAWK-737
URL: http://issues.apache.org/jira/browse/TOMAHAWK-737
Project: MyFaces Tomahawk
Issue Type: Improvement
Components: Html
TagHandler for tc:loadBundle has not the same behavor as the tc:loadBundle Tag
in a jsp
Key: TOBAGO-155
URL: http://issues.apache.org/jira/browse/TOBAGO-155
The main problem with handling these with lifecycle listeners is that
there is no guarentee your cleanup code is going to get called. In
general I agree with you, but if the lifecycle is shortcircuited, your SOL.
Scott
Arash Rajaeeyan wrote:
may be I don't get it correctly, but a good
FYI
http://wiki.apache.org/myfaces/Performance
On 10/12/06, yang ziming [EMAIL PROTECTED] wrote:
- 转发邮件
发件人： yang ziming [EMAIL PROTECTED]
收件人： [EMAIL PROTECTED]
已发送： 2006/8/19(周六), 下午1:15:39
主题： when STATE_SAVING_METHOD is client,the inputTextAjax not worked.
when i config the
yeah,
let's put a bunch of them to tomahawk.
On 10/12/06, Cagatay Civici [EMAIL PROTECTED] wrote:
I'm thinking of s:selectItems, also satisfies all the requirements in
http://wiki.apache.org/myfaces/promotion.
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog:
hey dude
an example is pretty much fine with me for testing that dhtml thing.
at least ensure, that firebug is not complaining :)
-M
Matze, one minor issue i see in this list, testcases
we do not have an infrastructure yet for dhtml components,
which has to be tackled in the long run.
As for
I agree with you here, I think pulling the defs the hard way
is the only option otherwise we will get into an utter mess.
Since we have not promoted too many components yet,
I was not sure if pulling the sandbox defs was a viable option,
given the userbase this code already has.
Scheper,
On one hand it is right that components of the sandbox are potential subjects
for change, but would it really hurt to do a slower deprecation? Like Werner
pointed out, some people are already using sandbox components in their
production environments although this may never have been recommended
Ernst Fastl schrieb:
On one hand it is right that components of the sandbox are potential
subjects
for change, but would it really hurt to do a slower deprecation? Like
Werner
pointed out, some people are already using sandbox components in their
production environments although this may never
[
http://issues.apache.org/jira/browse/TOMAHAWK-733?page=comments#action_12442088
]
Werner Punz commented on TOMAHAWK-733:
--
ttp://svn.apache.org/viewvc?view=revrevision=463811
moving the dojo codebase into tomahawk
[ http://issues.apache.org/jira/browse/TOMAHAWK-733?page=all ]
Werner Punz resolved TOMAHAWK-733.
--
Resolution: Fixed
All the needed work is done for now... the rest of the work on the codebase is
not related to the tomahawk promotion (typo fixes,
I agree ,If deprecation is not really possible ( for now I could also
not think of
a appropriate way to do so) then the clear cut has to be done sooner or
later anyway. And as erik-berndt already pointed out, the migration
for the users will be just a text-replace in their jsps or facelet-xhtml
I just resolved the last outstanding promotion related issue.
The dojo codebase now is in the Tomahawk trunk and can be used from
within Tomahawk!
So dojo will appear as for now in Tomahawk 1.1.5
(and hopefully some of the sandbox components as well)
I also will drop an official note at the
Validation doesn't run for required fields if submitted value is null
-
Key: MYFACES-1467
URL: http://issues.apache.org/jira/browse/MYFACES-1467
Project: MyFaces Core
Issue
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=all ]
David Chandler updated MYFACES-1467:
Status: Patch Available (was: Open)
Validation doesn't run for required fields if submitted value is null
Hi Dennis,
can you try to apply the patch for MYFACES-1467 and runing the TCK tests?
The javadoc for validate() says:
Retrieve the submitted value with getSubmittedValue(). If this returns
null, exit without further processing. (This indicates that no value
was submitted for this component.)
[
http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442108
]
Cagatay Civici commented on MYFACES-1467:
-
I've doubts about this, if submitted value is null it means the component isn't
submitted at all and it does
The problem was that you changed the TreeWalker interface. I've fixed
my TreeWalker implementations but everyone else is going to have to do
the same. I suggest at a minimum that you create a JIRA issue and
mark it resolved so it makes it into the release notes.
Sean
On 10/10/06, Martin
Hi Matze,
I'm on busineess/vacation in India right now for another week. After that I
have to move into a new apartment. Sorry I can't help on this soon. I would
be glad to help someone else through the testing process. I have corresponded
with Thomas on this recently.
Dennis Byrne
On 10/13/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Hi Matze,
I'm on busineess/vacation in India right now for another week. After that I
have to move into a new apartment. Sorry I can't help on this soon. I would
be glad to help someone else through the testing process. I have
[
http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442266
]
David Chandler commented on MYFACES-1467:
-
Agreed in part. It's actually a bug in the spec due to these conflicting
requirements:
Section 3.5.4
24 matches
Mail list logo
