Wow. No, I somehow missed the relevence of aliasBean on the facelets
mailing list.
For what it's worth, you're the first person in the history of
facelets to need it, at least as far as I've read on mailing lists.
Would it maybe be better to create a rendertime-compatible version of
ui:include
Hey Mario,
Thanks for keeping me honest :-)
You've been correcting a number of my misconceptions recently :-)
I went back and reread your facelets thread, and it does appear to be
a good dynamic ui:include. Why not use ui:param instead of f:param?
ui:param is already defined for facelets.
On
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
+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
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]
+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
renderkit-specific projects can take advantage of what's available.
On 10/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
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
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
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
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
and
aliasBeanScope. I don't think this special handling is included into
RI.
Regards,
Volker
2007/10/24, Mike Kienenberger [EMAIL PROTECTED]:
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
/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
+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
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
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
it there? Since I am not a regular contributor, I suspect I can't
just check it in :), so what is the proper process?
Thanks.
Val
On Wed, 2007-24-10 at 15:54 -0400, Mike Kienenberger wrote:
On 10/24/07, Val [EMAIL PROTECTED] wrote:
I handled the addition of a converter or validators
project (who would be the judge of that, btw?), what do I need to do to
get it there? Since I am not a regular contributor, I suspect I can't
just check it in :), so what is the proper process?
Thanks.
Val
On Wed, 2007-24-10 at 15:54 -0400, Mike Kienenberger wrote
I have another question.
Why were these three converters checked into Tomahawk with absolutely
no discussion and nothing going through the sandbox first?
I search my mail archives for AtomicLongConverter and the ONLY
reference to it is the commit itself.
-Mike
On 9/16/07, [EMAIL PROTECTED]
Should this also include myfaces-commons? I would expect Tomahawk to
build on myfaces-commons especially now that we're talking about
putting the common programming utilities into it, but I don't know if
that means it should be part of the Tomahawk super-project.
Second, JSF 1.1 requires jdk
Yes, this is perhaps another reason why this might best be placed
under Tomahawk.
We already have a Tomahawk sandbox in place for both Jdk 1.5 and
pre-1.5. Once a sandbox component is ready for promotion, part of
the evaluation could be deciding if it should go into the
works-with-anything
, Mike Kienenberger [EMAIL PROTECTED] wrote:
I think we're starting to confuse the focus here.
There's a difference between common components that can be used with
any JSF project, and common programming utilities, many of which may
be renderkit (like html) specific.
I'm ok with common
, Mike Kienenberger [EMAIL PROTECTED] wrote:
I have another question.
Why were these three converters checked into Tomahawk with absolutely
no discussion and nothing going through the sandbox first?
I search my mail archives for AtomicLongConverter and the ONLY
reference
And in case you somehow missed the other messages (which is why
Matthias started this thread), I've now reverted this from Tomahawk
due to Java 1.5 dependencies (and a lack of discussion beforehand).
For now, I'd recommend either committing it to sandbox15 or to MyFaces 1.2.
On 10/26/07, Dennis
No, it's not. There are components in Tomahawk that depend on
javascript. There are components in tomahawk that depend on MyFaces
core (aliasBean). There are components in Tomahawk that depend on
dojo. There are components in Tomahawk that depends on the MyFaces
form.
Right now, Tomahawk
I don't think there's any hard rule that all projects have to be
prefixed with MyFaces.
But then, I also don't have any problem with it being associated with
Tomahawk or MyFaces (in the name).
On 10/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
I agree that MyFaces Basics is too
From what little I understand of maven, this looks like a good idea.
However, I think that with the proposal of a MyFaces Basics/Commons
project and a MyFaces Facelets project, that Tomahawk restructuring
should wait a few days. I'm still not seeing any consensus on what
these projects are
Note: pure speculation.
Possibly it's due to the misunderstanding that the #{blah} part of
the string is the EL expression.
Any string is an EL expression, and #{} is simply one operator that
can be used in that string. So #{a} text #{b} text #{c} is one EL
expression, not three.
On 10/30/07,
Well, I think there's probably enough difference between the two goals
that we do need to separate projects, even though it contributes to
the Yet Another MyFaces Subproject quagmire. At least it's a step
in the right direction since we're looking at merging common code
rather than futher
We're discussing two completely different concepts here.
One is an api for writing new components. For component developers.
One is a library of common renderkit-independent components for use in
JSF applications. For application developers.
Attempting to combine them is going to shortchange
Please open a JIRA issue and attach your changes as a unified diff patch.
-Mike
On Nov 20, 2007 9:47 AM, Vorobjov, Dmitriy (DB) [EMAIL PROTECTED] wrote:
Guys,
I implemented TODO null-check for Weblogic, that tries to initialize
Servlet before ContextListener in FacesServlet class
For html, I think we should continue to render .
For xhtml, we should render amp;
On Nov 21, 2007 7:37 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
Please have a look at
http://issues.apache.org/jira/browse/MYFACES-1774
Do you think there is a problem with generally rendering amp; instead of
the HtmlDataTable
component still uses SortableModel class to set the current sort column.
Wouldn't be normal to use BaseSortableModel class to allow extensibility?
Thanks.
Mike Kienenberger wrote:
As a first step in this process, I've separated SortableDataModel into
SortableDataModel
;
/**
* @author Mike Kienenberger (latest modification by $Author: mlk $)
* @version $id$
*/
public class SortableHtmlDataTable extends HtmlDataTable
{
private static final Log log =
LogFactory.getLog(SortableHtmlDataTable.class);
public static final String COMPARATOR_FACET_NAME = comparator
If you're going to support 1.1, support 1.4. Otherwise, just stick
with JSF 1.2.
I know where I do my primary JSF work, the major holdup has been JDK
1.5, which was only recently adopted, not JSF 1.2, per se.
I'm personally good with JSF 1.2 only, though, for this new project.
On Dec 3, 2007
+1
On Dec 5, 2007 1:46 PM, Andrew Robinson [EMAIL PROTECTED] wrote:
Lets make the myfaces commons JSF API an official vote so we can have
a fixed time frame on this decision
+1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
commons project
+0 [ ] -- you don't mind
At least in terms of the validators/converters/etc (non-api) parts of
commons, it is not intended that Tobago or any other project depend on
these. These are additional components made available to the end
users. So it's true that some small subset of Tobago users won't be
able to use it.
Can't you do something like this to force the rt.jar to be 1.4?
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html
% javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip -extdirs
OldCode.java
On Dec 20, 2007 10:11 AM, Simon Kitching [EMAIL PROTECTED] wrote:
This problem
:
Mike Kienenberger [EMAIL PROTECTED] schrieb:
Can't you do something like this to force the rt.jar to be 1.4?
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html
% javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip -extdirs
OldCode.java
Yep. However that cannot be put
If something was publicly released as 1.2.1 already, then -- even if
it was pulled -- please do not release 1.2.1 again.
Skipping a version number might cause some questions on the list.
However, reusing a version number will result in the end user not
knowing if they have the good version or the
On Jan 21, 2008 4:10 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
If something was publicly released as 1.2.1 already, then -- even if
it was pulled -- please do not release 1.2.1 again.
it wasn't released. Just
http://wiki.apache.org/myfaces/Code_Generation
2) Generating base classes instead of templates from xml-config-files
For what it's worth, what you're describing here is the Generation Gap
pattern. I've got a lot of experience using it with Cayenne over the
years (and WebObjects years before
I've been following this thread on and off, so my apologies if you
already covered it,
but how different will syntax checking be with the javadoc annotations
vs xml? Xml editors automatically validate with schemas or dtds. Is
something similar available for javadoc annotations in the standard
,
Simon
On Fri, 2008-03-21 at 14:40 -0400, Mike Kienenberger wrote:
I've been following this thread on and off, so my apologies if you
already covered it,
but how different will syntax checking be with the javadoc annotations
vs xml? Xml editors automatically validate with schemas
I have not seen the specifics of this project, but if you're using
velocity, you should be able to have the code which initializes
velocity automatically populate something like $utils instead of doing
it in the velocity template language.
I also think you're better off NOT putting
On Thu, Apr 3, 2008 at 7:44 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
The drawback
is that creates a log file on the project folder (I'm not found how to
output the log on the screen yet!).
Have you looked at this page?
Another alternative to option 1 is to #parse($fileName) or #include($fileName).
You can specify filename externally. This is probably the best
solution so long as the contents of the file included can be included
as-is.
On 4/9/08, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
I have another
On 6/4/08, Leonardo Uribe [EMAIL PROTECTED] wrote:
* @JSFJspProperty name = message inheritedTag=true returnType =
java.lang.String longDesc = alternate validation error message format
string
*/
public class CSVValidator extends ValidatorBase
Inheritance of properties for converters and
are subclassing a converter, there's
obviously some reason why you did it rather than writing one from
scratch.
On 6/4/08, Leonardo Uribe [EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 3:21 PM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
On 6/4/08, Leonardo Uribe [EMAIL PROTECTED] wrote
I'd recommend not migrating t:validateEqual across to myfaces-commons.
t:validateEquals is a special case of t:validateCompareTo, and, if I
recall correctly, the code in validateEquals is not as flexible as the
code in validateCompareTo. There's no point in maintaining the
inferior limited
+1 to promoting subform.
+1 to everything Volker said.
On 6/11/08, Volker Weber [EMAIL PROTECTED] wrote:
Hi Hazem,
i think you are a bit to fast. You started the vote at 9. Juni 2008 17:54
start committing the changes 44:20 hours:minutes (if i count correct)
later at 11. Juni 2008 14:14.
Use the sandbox convertNumber with a BigDecimal type.
You may also want to take a few minutes and add the workaround for the
bug in the java currency parser (DecimalFormat) as described in
http://issues.apache.org/jira/browse/TOMAHAWK-610
if it hasn't already been taken care of.
On 6/13/08,
PROTECTED] wrote:
thanks!
will have a look
On Fri, Jun 13, 2008 at 6:04 AM, Mike Kienenberger [EMAIL PROTECTED] wrote:
Use the sandbox convertNumber with a BigDecimal type.
You may also want to take a few minutes and add the workaround for the
bug in the java currency parser
http://myfaces.apache.org/trinidad/download.html
If it's not in a pre-build download, you can check it out from svn by
following the instructions on the same link above.
On 6/13/08, Ivan Li [EMAIL PROTECTED] wrote:
I download the source code from apache, but the the core component's source
/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 6:04 AM, Mike Kienenberger [EMAIL PROTECTED] wrote:
Use the sandbox convertNumber with a BigDecimal type.
Ok,
I don't use this now.
Since Java5 there is a parseBigDecimal() on DecimalFormat.
In Trinidad I just turn
Number is null.
5. Otherwise, the value passed validation.
--
On 6/16/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Mon, Jun 16, 2008 at 6:21 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
On Mon, Jun 16, 2008 at 6:19 PM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
Yes
It should be deprecated because it adds nothing over validateCompareTo
and does not do the job of locating/computing/comparing two equal
input component values as well as validateCompareTo does.
Or to look at it another way, defining a validateEquals jsp or facelet
tag handler that points to the
Let's not forget that working on open source software is quite
different than working on proprietary software. For open source, you
work on what you need and you share what you've done with others.
Some people need JSF 1.1 and will be working there. Some people need
JSF 1.2 and will be working
On 6/25/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
s:validateCompareTo
And all that code about independently converting a component's submitted
value makes me a little nervous. It looks ok, but has anyone properly
reviewed it?
The code was pretty much copied verbatim from the Myfaces
On 6/25/08, simon [EMAIL PROTECTED] wrote:
On Wed, 2008-06-25 at 10:59 -0400, Mike Kienenberger wrote:
On 6/25/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
s:validateCompareTo
And all that code about independently converting a component's submitted
value makes me
On 6/26/08, Volker Weber [EMAIL PROTECTED] wrote:
Does it really matter if there's a commons 1.1? Tomahawk 1.1 is fast
approaching the end of its lifecycle.
Yes, it does. At least to me.
Commons1.1 is not a tomahawk1.1 extension, it should contain things
for jsf1.1 application
If I understand correctly, the current state of the component is such
that it works with any UIData component. I'm +1 for keeping that
status. It'd be great if we could do something similar with many of
the other t:dataTable functionality.
On 6/27/08, simon [EMAIL PROTECTED] wrote:
I'm +1 to
I agree with Simon in that where the image usage is not under our
control (like t:graphicImage), we should not output an alt tag unless
the end-user specifies an alt tag.
On Mon, Jun 30, 2008 at 4:50 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
On Mon, Jun 30, 2008 at 12:15 AM, Hazem Saleh
What Simon proposed makes a lot of sense to me.
On Wed, Jul 2, 2008 at 1:18 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Andrew Robinson schrieb:
You must have had a real use case that pushed you to write this
component.
Can you please describe it?
The same as all usages of c:choose /.
This will still crash if rc.getAgent() ever returns null. I don't
know if that's a possibility.
On 7/8/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: matzew
Date: Tue Jul 8 09:41:52 2008
New Revision: 674871
URL: http://svn.apache.org/viewvc?rev=674871view=rev
Log:
, Jun 13, 2008 at 6:04 AM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
Use the sandbox convertNumber with a BigDecimal type.
Ok,
I don't use this now.
Since Java5 there is a parseBigDecimal() on DecimalFormat.
In Trinidad I just turn that guy on. So, that fixes it.
Sandbox still
Sure, that's what the section is for.
On 7/14/08, Jihoon Kim [EMAIL PROTECTED] wrote:
So that is the update and I was hoping if I could modify the
Frameworks related to JSF section within the MyFaces Wikipage to
include a link to FlexFaces project in order to increase the exposure
of the
I think what Manfred is suggesting is that we implement a reCAPTCHA
component specifically rather than captcha in general. For those
people who want to secure their applications and promote digital book
scan correcting at the same time :-)
On 8/14/08, Hazem Saleh [EMAIL PROTECTED] wrote:
Hi
Rob Williams describes some of the pain I've experienced in the past
with JSF. You have complicated Domain dynamic hierarchies. You
don't want to be trying to create a dynamic hierarchy of Data Transfer
Objects that you then have to maintain, populate and transfer. So
what do you do?
Ryan
+1 only for components that don't render anything, like t:saveState
On Fri, Oct 24, 2008 at 5:27 AM, Simon Kitching [EMAIL PROTECTED] wrote:
The latest maven-clirr-report plugin unfortunately crashes on orchestra, but
I have created a report using clirr trunk; please see here:
http://myfaces.apache.org/tomahawk/source-repository.html incorrectly
gives the online svn repository link as follows:
http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk/tomahawk-site
I'm guessing it should be:
http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk
evaluated it.
On Tue, Feb 20, 2007 at 10:52 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
Does this help?
#Generated by Maven
#Thu Apr 13 14:18:08 EDT 2006
version=2.0.0
groupId=org.apache.myfaces.shared
artifactId=myfaces-shared-impl
So perhaps the change that needs to be made
What about Simon's suggestion that we promote it to commons instead of
Tomahawk? Any reason not to go down that path?
On Wed, Nov 12, 2008 at 8:21 PM, Hazem Saleh [EMAIL PROTECTED] wrote:
Refactoring is done.
Tomorrow will promote the component to Tomahawk.
On Wed, Nov 12, 2008 at 11:00 PM,
Robinson [EMAIL PROTECTED]
Since it doesn't render anything, perhaps it should?
On Thu, Nov 13, 2008 at 12:27 PM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
What about Simon's suggestion that we promote it to commons instead of
Tomahawk? Any reason not to go down that path?
On Wed, Nov
+1
On 11/14/08, Grant Smith [EMAIL PROTECTED] wrote:
+1
On Fri, Nov 14, 2008 at 7:41 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
+1
On Fri, Nov 14, 2008 at 4:36 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
+1
On Thu, Nov 13, 2008 at 4:21 PM, Gerhard Petracek
I'd say that there's no reason to deprecate a class clearly packaged
as trinidadinternal.
On 11/14/08, Jeanne Waldman [EMAIL PROTECTED] wrote:
Actually, I decided to be on the safe side to deprecate it, even if it is
just for one release.
Jeanne
Jeanne Waldman wrote, On 11/14/2008 9:03 AM
Just a comment that Sameo isn't useful if someone doesn't see this
in the context of the previous commit.
On Mon, Nov 24, 2008 at 7:02 PM, [EMAIL PROTECTED] wrote:
Author: sobryan
Date: Mon Nov 24 16:02:10 2008
New Revision: 720358
URL: http://svn.apache.org/viewvc?rev=720358view=rev
Log:
+1
On Tue, Jan 20, 2009 at 4:04 PM, Scott O'Bryan darkar...@gmail.com wrote:
Hey community,
Oracle is trying to open up a new JSR for the Portlet 2.0 Bridge.
Originally this was part of the JSR-301 but there was a slight
misunderstanding of the intentions of the specs regarding release
Make sure you're doing all work in the JSF component, and none in a
JSP tag handler. The tag handler should simply assign properties set
on the tag to the component.
That will take care of the problem in general. There are specific
cases where no component exists that have to be handled by
A simple pluggable API sounds like a reasonable approach to me. For
some situations, a pure reflection scanner might work better. For
others, it won't scale. You might need to temporarily switch to a
different scanner to determine if it's the cause of some particular
bug. Or perhaps the
Unfortunately, I don't have any knowledge about the ajax work you are
all doing. However, I am -1 on anything that tries to intentionally
break spec compatibility, such as reusing the f: namespace. Even if
it's not explicitly spelled out, we know that it's against the spirit
of the spec. I find
I don't know much about git, but I know that other committers on
Apache Cayenne use git to commit to the Cayenne svn, so it's certainly
possible to do what Andrew suggests. From my limited git
understanding, that's the typical practice of using git -- as a
front-end to svn or cvs.
On Fri, May
Yes, I looked at this library for GWT work a couple weeks ago. It's
compatible in theory, but not in practice.
On Wed, May 27, 2009 at 6:23 AM, Ganesh gan...@j4fry.org wrote:
AFAIK ExtJS may not be altered and resold commercially - they have a 2nd
commercial license. The whole thing is
Is this really a bug? I'd say it's a feature. Some design experts
insist that buttons merely be greyed out rather than removed when
inactive. That would not be possible if the next/previous facets are
not rendered at all times. I'd say that the children of that facet
should be able to
I'd strongly prefer to see JUL instead of something else (including
JCL) now that it's part of the standard. In Ganesh-speak, +0.9 JUL,
-0.9 slf4j
On Sat, Jun 6, 2009 at 6:37 AM, Mario Ivankovits ma...@ops.co.at wrote:
Hi!
The only downside I see is that we might break compatibility for java
+1
On Tue, Jun 9, 2009 at 2:56 PM, Curtiss Howardcurtiss.how...@gmail.com wrote:
On Tue, Jun 9, 2009 at 2:32 PM, Gerhard
Petracekgerhard.petra...@gmail.com wrote:
hi,
short description:
this first vote is about the switch from commons-logging (cl) to
java.util.logging (jul).
it's a
I was looking for a 1.1.9 sandbox snapshot prebuilt.
Our link to the maven repository points to a Nov 2008 version.
http://wiki.apache.org/myfaces/FAQ#download-other-stuff
I looked around for a bit trying to find something more current, but I
wasn't able to do so.
Do we no longer produce
For awhile, 2.0 changes for facelets were being committed to the
JSF_2_0_0_from_HEAD_20080606_BRANCH facelets branch.
I'm not sure if that's still the case or if the branch was forked elsewhere.
On Wed, Aug 5, 2009 at 9:11 AM, Matthias Wessendorfmat...@apache.org wrote:
On Wed, Aug 5, 2009 at
Probably in the facelets repository, if it's not part of the JSF 2.0
implementation.
:pserver:user@cvs.dev.java.net:/cvs
Branches include:
JSF_2_0_0_AJAX
JSF_2_0_0_AJAX_20080713_BRANCH
JSF_2_0_0_from_HEAD_20080606_BRANCH
On Thu, Aug 6, 2009 at 9:26 AM, Curtiss
Looking at someone else's code and then writing your own version is a no-no.
However, there's a legal way to deal with it. Clean-room reverse engineering.
Here's an example of how it was done with wireless driver support for
linux -- good overview of the proper process.
+1 for jul -- it's not ideal, but it's the standard and doesn't
require any dependencies.
On Thu, Oct 1, 2009 at 12:22 PM, Grant Smith work.gr...@gmail.com wrote:
+1 java.util.logging.Logger
On Thu, Oct 1, 2009 at 9:14 AM, Michael Concini mconc...@gmail.com wrote:
+1 for JUL
Antonio
Should we consider deprecating t:updateActionListener in 1.2 and
removing it in 2.0 now that f:setPropertyActionListener exists?
Perhaps for 1.2, we should consider making the tag an alias for
f:setPropertyActionListener component rather than a separate
component.
As far as I know, there is no
Really?
I'd think if the direct child t:dataList isn't rendered, we probably
shouldn't output the tag.
But it's our own component, so we can make whatever rules we want.
On Wed, Feb 3, 2010 at 2:31 PM, Leonardo Uribe (JIRA)
dev@myfaces.apache.org wrote:
[
Jodi is too similar to Joda time in my opinion.
http://joda-time.sourceforge.net
On Mon, Feb 8, 2010 at 4:29 AM, Hazem Saleh haz...@apache.org wrote:
in case of JODI it's:
J ... JSF
O ... cOntext
DI ... Dependency Injection.
I can feel the musical tone in this name more :).
On Mon,
Can it be made into a configuration option?
On Tue, Feb 9, 2010 at 1:25 PM, Matthias Wessendorf mat...@apache.org wrote:
... on the other hand, the EG says, that JSF2.0 RT can be used to
deploy a JSF1.2 based application.
Since Facelets was just some random proprietary framework, ignoring
the
Never mind. I see in the jira issue that it's possible to drop in the
old facelets implementation. That seems like the right approach to
me.
On Tue, Feb 9, 2010 at 1:27 PM, Mike Kienenberger mkien...@gmail.com wrote:
Can it be made into a configuration option?
On Tue, Feb 9, 2010 at 1:25 PM
I agree with Leonardo that changes which affect our base requirements
(jdk 6 instead of jdk 5) and which could compromise our certification
warrant discussion rather than a commit-and-hope-no-one-complains
attitude.
Otherwise, without discussion, how would we know that Mojarra allows it?
On Thu,
I'm happy with the current wiki, and I haven't enjoyed working with
confluence. We also seem to have a lot of assorted problems with it
on the Cayenne project.
But I'm not opposed to switching if that's what everyone else really wants.
On Wed, Mar 24, 2010 at 2:35 PM, Jakob Korherr
You might want to consider Selenium
http://seleniumhq.org/
Apache 2.0 license
On Thu, Mar 25, 2010 at 8:25 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
Hi,
As we currently only have normal JUnit tests for automated testing in
MyFaces Core, it would be really great to have a way to test
I'm not an expert on svn so I can't answer your specific question, but
if you can't find a solution, you could commit everything to a branch,
then merge to trunk individually.
On Sun, Apr 4, 2010 at 7:08 AM, Mark Struberg strub...@yahoo.de wrote:
Hi!
I have a really fu SVN problem.
I did
701 - 800 of 1572 matches
Mail list logo