MyFaces community BOF at J1
Hi *, we (Manfred and me, but get in contact with us if you are at J1, we'll share the stage!) have been accepted for a MyFaces community BOF at J1, and as the community is the most important asset in this project, we'd like to talk about the community. What I've thought about is to do a session where we show a photo of each of the MyFaces committers, nationality (so that we can show how different we are in region), age, and a funny statement with regards to her/him (either what she/he said or what one can say about her/him), and then what she/he's done for the MyFaces project (so we're introducing MyFaces and what it can do by introducing the MyFaces community). Now I've got three questions for you: - Is that an idea you'd approve of? - Would you be willing to send me photos until Tuesday the latest? - Would you be against being shown on a J1 presentation with your photo, plus a funny remark, which will hopefully be tasteful and not disgraceful ;) regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces community BOF at J1
Well, that's an exceptionally good title as well! thanks Bruno. regards, Martin On 4/27/07, Bruno Aranda [EMAIL PROTECTED] wrote: Hehe The Faces of MyFaces, focusing the community, the pillar of the project, is a good idea. No problems for me :-) Cheers, Bruno On 27/04/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, we (Manfred and me, but get in contact with us if you are at J1, we'll share the stage!) have been accepted for a MyFaces community BOF at J1, and as the community is the most important asset in this project, we'd like to talk about the community. What I've thought about is to do a session where we show a photo of each of the MyFaces committers, nationality (so that we can show how different we are in region), age, and a funny statement with regards to her/him (either what she/he said or what one can say about her/him), and then what she/he's done for the MyFaces project (so we're introducing MyFaces and what it can do by introducing the MyFaces community). Now I've got three questions for you: - Is that an idea you'd approve of? - Would you be willing to send me photos until Tuesday the latest? - Would you be against being shown on a J1 presentation with your photo, plus a funny remark, which will hopefully be tasteful and not disgraceful ;) regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Graduation] Trinidad voted out of Incubator
Great Matthias! Keep up the good work... regards, Martin On 4/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: yes, all lists are moving. My pref. would be [EMAIL PROTECTED] instead of using the standard myfaces lists; -M On 4/22/07, Adam Winer [EMAIL PROTECTED] wrote: Woo-hoo! Thanks to all the contributors. Are we also going to move the issue list over? -- Adam On 4/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Dear Trinidad community, The Trinidad PPMC is pleased to let you know, that Trinidad has been voted out of the Apache Incubator. We got 12 binding +1 votes by the Apache Incubator PMC, and two more non-binding by the Incubator community (see [1]). Trinidad graduates as a subproject of the Apache MyFaces community. The next steps are allocating a SVN folder w/in the MyFaces SVN repo. The mailing lists will also be moved to myfaces. I think I can speak for all of us, that we have 13 interesting month (11,5 with sources in the SVN ;)) behind us, and we are happy to announce that leaving the Incubator has become reality. Thanks to all of you for participating in this community. Without that this never had been possible. This project has proven that Apache-style OpenSource (community-focused) is a good choice! -Matthias [1] -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: blank page when running demo !?
Do you use tomcat 5.5.x? Did you get rid of jsp20.jar and commons-el.jar in your WEB-INF/lib directory? regards, Martin On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: and the website from the Austrian company Irian (a JSF consulting company) serves the current Trinidad demo as expected as well: http://example.irian.at/trinidad-demo-20070419/faces/index.jspx -M On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: mvn clean install on the trunk went through; the created WAR I put into Tomcat 5.5.x and it worked. -M On 4/19/07, Cristi Toth [EMAIL PROTECTED] wrote: Hi, I have a problem running the demo project. When I run it from IntelliJ Idea it always returns a blank page I did a clean checkout, build it with maven, built the Idea project with maven and ran it. My config is: Win XP SP2 Java 1.5.0_11 Idea 6.0.5 Does anyonw have an idea what's wrong? P.S. I also tried on Exadel (eclipse) but I got some weird class not found problem although the dependenices were ok -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Next steps? (was Re: Is trinidad ready for graduation ?)
As long as the community is somewhat similar (at least there are people in both communities), I'm +1 for taking it in under MyFaces. My only problem with the subproject approach is that when RCF comes out, we'll have two sub projects where one sub project depends on the other - kind of awkward. regards, Martin On 4/11/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Simon, I like your arguments and after reading this thread, I like the idea of a subproject better than a TLP too. I wanted to comment so ya'll will know there are more people reading the thread and forming an opinion than have been commenting thus far. :) - Jeanne Simon Lessard wrote: Personally I don't think a TLP would be a good idea just yet since JSF is still relatively new compared to some older well known frameworks. I think it's easier for new users to find all they need from one entry point and MyFaces seems the right place for that, at least for now. Also, being a subproject will probably improve the users' confidence in library compatibility as well as encourage that compatibility to be kept/improved by developers. It may just be a feeling, but it seems to me that making Trinidad TLP right away would make it look a bit like a loner, especially since Tobago and Tomahawk are MyFaces sub projects. If JSF component sets should be TLP(s), then I think it should be done all at the same time, and this cannot be achieved until we harmonize Tomahawk, Trinidad and Tobago imho. My 2¢, ~ Simon On 4/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: That was also a point of Noel, when proposing the RCF donation thing. He was asking, why not having a JSF components project. Perhaps that might be an interesting option, not sure yet; but when RCF arrives somewhen.. there would be another component set. Perhaps we should move the discussion for a split to the MyFaces DEV list, that the MyFaces PMC is also able to comment. The components project could have a similar fashion like Jakarta. But since this isn't yet the case, I'd agree that a subproject is the best, for now. -Matthias On 4/11/07, Adam Winer [EMAIL PROTECTED] wrote: If there was an idea to split MyFaces into an implementation half and a component set half, each as separate TLPs, then I'd see your point - but as it is, MyFaces the TLP is both an implementation and (currently) 2 component sets. -- Adam On 4/10/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Sorry for the one in all reply.. Ok, let's switch perspective's here. MyFaces (the codebase) is a JSF implementation. Tomahawk and Trinidad are JSF component sets. I am not comparing the possible overlap of the component sets, I am focussing on the possible lack of overlap in community of the JSF implementation and the component sets. Different goals, different users and different developers (although the last is not yet the case, it is most likely someone interested in components is not interested in coding on the JSF implementation). Just playing bad cop here though, to hopefully prevent this situation (if you are aware of these signs you can watch out for it) Not going to vote -1 on a move to MyFaces. Mvgr, Martin -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Problem with showOneAccordion
Ok, I see.
I've been spending some hours yesterday debugging through this thing,
and I don't know why, and don't know how, but obviously the right
stuff is being rendered out (I see the right responsewriter calls,
i.e. one call for an opened showOneDetail), but the client gets wrong
stuff in the PPR response (i.e. all closed showOneDetails).
Is there anything in between the call to the response writer and the
output that is sent to the client that I'm missing, or have I only
been to tired yesterday and mixed things up?
As an additional hint: the examples of panelAccordion (which are by
the way called showOneAccordion and showManyAccordion) from a while
ago (partially) work:
http://www.irian.at/trinidad-demo/faces/components/showOneAccordion.jspx
the current examples don't:
http://example.irian.at/trinidad-demo-20070404/faces/components/showOneAccordion.jspx
regards,
Martin
On 4/5/07, Adam Winer [EMAIL PROTECTED] wrote:
panelAccordion is rather badly broken, last I checked.
See http://issues.apache.org/jira/browse/ADFFACES-398
And the renderer code for panelAccordion, panelRadio,
panelChoice... shudder. Roughly speaking, everything
in org.apache.myfaces.trinidadinternal.renderkit.html.layout
needs to be rewritten.
-- Adam
On 3/28/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi again,
I've looked at the combined code for CorePanelAccordion and
UIXShowDetail and their renderers and I wonder why the code for doing
the disclosure/closure is spreaded out so much. Wouldn't it be better
to handle this in the detail and the parent components, and in the
renderer only do the rendering of the component? That should be
possible with the event system, right?
regards,
Martin
On 3/29/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi *,
can anyone of the Trinidad core developers do me a favour and look at:
http://example.irian.at/trinidad-demo-20070328/faces/components/showOneAccordion.jspx
do you think the behaviour is what a user expects? I would not think
so... When I click on Panel 1 and then on Panel 2, I would suspect
Panel 2 to be opened afterwards, but it isn't.
I've added the following code to CorePanelAccordion to make this work again:
@Override
public void queueEvent(FacesEvent event) {
super.queueEvent(event);
// Deliver to the default ChartDrillDownEvent
if (event instanceof DisclosureEvent)
{
List li = this.getChildren();
for(int i=0; ili.size(); i++) {
UIComponent comp = (UIComponent) li.get(i);
if(comp instanceof UIXShowDetail) {
((UIXShowDetail) comp).setDisclosed(false);
}
}
}
}
but - this code will need to be restricted to take events only of
direct children, and only for showOneAccordions. Apart from this -
would you think this is the right approach for a fix?
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Problem with showOneAccordion
Hi *,
can anyone of the Trinidad core developers do me a favour and look at:
http://example.irian.at/trinidad-demo-20070328/faces/components/showOneAccordion.jspx
do you think the behaviour is what a user expects? I would not think
so... When I click on Panel 1 and then on Panel 2, I would suspect
Panel 2 to be opened afterwards, but it isn't.
I've added the following code to CorePanelAccordion to make this work again:
@Override
public void queueEvent(FacesEvent event) {
super.queueEvent(event);
// Deliver to the default ChartDrillDownEvent
if (event instanceof DisclosureEvent)
{
List li = this.getChildren();
for(int i=0; ili.size(); i++) {
UIComponent comp = (UIComponent) li.get(i);
if(comp instanceof UIXShowDetail) {
((UIXShowDetail) comp).setDisclosed(false);
}
}
}
}
but - this code will need to be restricted to take events only of
direct children, and only for showOneAccordions. Apart from this -
would you think this is the right approach for a fix?
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
selectRangeChoiceBar
Hi *, http://example.irian.at/trinidad-demo-20070328/faces/components/selectRangeChoiceBar.jspx gives a nasty exception - any clue why this is so? Is this just a problem of our deployment? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Problem with showOneAccordion
Hi again,
I've looked at the combined code for CorePanelAccordion and
UIXShowDetail and their renderers and I wonder why the code for doing
the disclosure/closure is spreaded out so much. Wouldn't it be better
to handle this in the detail and the parent components, and in the
renderer only do the rendering of the component? That should be
possible with the event system, right?
regards,
Martin
On 3/29/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi *,
can anyone of the Trinidad core developers do me a favour and look at:
http://example.irian.at/trinidad-demo-20070328/faces/components/showOneAccordion.jspx
do you think the behaviour is what a user expects? I would not think
so... When I click on Panel 1 and then on Panel 2, I would suspect
Panel 2 to be opened afterwards, but it isn't.
I've added the following code to CorePanelAccordion to make this work again:
@Override
public void queueEvent(FacesEvent event) {
super.queueEvent(event);
// Deliver to the default ChartDrillDownEvent
if (event instanceof DisclosureEvent)
{
List li = this.getChildren();
for(int i=0; ili.size(); i++) {
UIComponent comp = (UIComponent) li.get(i);
if(comp instanceof UIXShowDetail) {
((UIXShowDetail) comp).setDisclosed(false);
}
}
}
}
but - this code will need to be restricted to take events only of
direct children, and only for showOneAccordions. Apart from this -
would you think this is the right approach for a fix?
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: selectRangeChoiceBar
Well, that I would have guessed as well ;) I was just wondering if this happens maybe just on MyFaces and not on RI or so? regards, Martin On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: the facet is causing the nice exception On 3/29/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, http://example.irian.at/trinidad-demo-20070328/faces/components/selectRangeChoiceBar.jspx gives a nasty exception - any clue why this is so? Is this just a problem of our deployment? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: about maven-faces-plugin
I still wonder if the approach MyFaces originally had wasn't better
than the new approach of the generator in Trinidad.
Apart from the fact of course that generation should happen on every
run of the build - we kind of neglected that.
What you have with the Trinidad generator now is:
...Template.java:
...
void myMethod() {
setMyProperty(test); //won't compile, cause setMyProperty is autogenerated!
}
with the MyFaces initial method, this was all in one file, with special markers:
Component.java
void myMethod(){
setMyProperty(test); //compiles, cause in the same file
}
/** auto generated begin - don't change this code **/
public void setProperty(String property) {...}
/** auto generated end - don't change this code **/
regards,
Martin
On 3/7/07, Adam Winer [EMAIL PROTECTED] wrote:
On 3/7/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
what I didn't like this morning, for fixing a bug on MyFAces' JSF 1.2
UIViewRoot is,
that I need to put this statement:
/**///getPhaseListeners
to get a *ignored* getter for the phaseListeners property.
Well, you need this if you're going to try to compile
the template, and you need to refer to a method that will
be auto-generated from code that isn't auto-generated.
If you're not compiling the template, that's not necessary.
It's certainly not pretty - an annotation of some sort
would be way better - but it has the distinct advantage
of being a piece of logic that I could code in minutes.
(The principle of Good Enough applies. :) )
-- Adam
The rest is fine, at least the part I was dealing w/ in order to get
some stuff working in Trinidad
-M
On 3/7/07, Adam Winer [EMAIL PROTECTED] wrote:
In general, I think the approach used by the faces plugin
is a really good thing. You want as much autogenerated
as possible (this made upgrading to JSF 1.2 vastly easier
than without it). And the specific approach actually
allows for treating the template .java files as fully
compileable sources - you can add them to your IDE
and get full code insight, syntax checking, etc. Most
systems I've seen for templated code don't offer that;
the templated Java is pseudo-code that no IDE will
accept.
I agree with Bruno that the plugin could definitely
be improved... some injection might be good,
velocity templates for method generation would
probably be wy easier than all the Java code, etc.
-- Adam
On 3/7/07, Bruno Aranda [EMAIL PROTECTED] wrote:
IMO I prefer to use as much as I can the code autogenerated without
having to add new code to the methods (delegating all this to the code
generator). This eases the process of migrating code. Adding very
specific code to methods might break future migrations (e.g. migrating
tomahawk components to use trinidad state management), as the specific
code could no longer compile. Of course, this can be a minor thing so
I am open to this possibility of injecting code before/after the
method's logic, as aspects do. How would you do it, though?
And of course, there is a great space for improving in the plugin and
it would be wonderful at some point to have it based in velocity,
Cheers,
Bruno
On 07/03/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Hi all,
During myfaces 1.2 development I came across the maven-faces-plugin from
trinidad. AFAIK it uses some xml files which contains the model for
the generated components. This saves a lot of time to quickly get new
components into work. But there is room to improve it.
Currently customizing the generated component classes requires to
write a template file (like UIViewRootTemplate.java) which contains
custom code. I don't like this approach. Since there is no chance to
modify generated methods and to add custom code. That is even worse if
you only want to add something to save/restore state methods or to add
some parameter checking for setters. I've already seen that some dirty
hacks are implemented to make things work - at least for using it in
myfaces.
IMO there is a way to solve some of the problems by still having
generated code. I'm thinking of an in place editing the generated
code inside special marks like this:
public void setXXX(String xxx)
{
/* start custom code */
// do something before the generated code
/* end custom code */
_XXX = xxx;
/* start custom code */
// do something after the generated code
/* end custom code */
}
WDYT?
--
Mathias
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Getting the Component ID from within getOnclick()
Well, if the component is not passed in, you can't. The question is if the method signature should be changed. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Sorry, I should have been clearer. In the renderer code on the server-side my component overrides the XhtmlRenderer.getOnclick() to insert some custom javascript. Within this method I'd like to be able to call getClientId() on the component to grab the id. Currently I'm having to use eval combined with this.id to workaround this issue, but it's not very clean. Danny On 2/27/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Keeping in mind that I have barely a day's worth of practical javascript experience, maybe this.id or something along those lines? On 2/27/07, Danny Robinson [EMAIL PROTECTED] wrote: anyone ;-) On 2/23/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Any advice on how to easily retrieve the component ID from within an overridden method such as XhtmlRenderer.getOnclick(). The only parameter to this is FacesBean.Type, and not the component itself. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Client-side validation - enhance to match server-side
I've been reiterating the necessity for this time and again ;) - I'd be pretty much for an addition like this. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Oracle Skin Release
I'd love to have it somewhere in Trinidad - but where to put it? A section on the website for the download of the jar, and a certain directory in the repository? By the way: you should probably rename the image directory to something not containing oracle/adf/... regards, Martin On 2/8/07, Mark Robinson [EMAIL PROTECTED] wrote: I've updated the skin as we've discussed. It's now available from: http://www.engr.uvic.ca/~mrobinso/RedwoodShores.jar Is there any interest in incorporating this into a central skin repository? Mark Adam Winer wrote: Thanks, I've created ADFFACES-371 to track getting rid of the old images. -- Adam On 2/2/07, Mark Robinson [EMAIL PROTECTED] wrote: Adam, I've got all the images I need packaged up in my JAR file. So you can remove the images from Trinidad. I can change the name fairly easily. I think RedwoodShores might be the best name ;) Mark Adam Winer wrote: Mark, FWIW, we probably should have deleted those images from Trinidad. Not because of licensing or anything - their license is fully transferred to Apache! - but because they're unused inside of Trinidad. I'd like to be able to delete them from Trinidad, and have them packaged with the skin that uses them. So, if there's any way you could incorporate the images you use into your skin's JAR, that would be great. Also, I'd recommend that you choose some new name for the skin, just to avoid any questions of ownership/copyright, etc., down the road. Cheers, Adam On 1/30/07, Mark Robinson [EMAIL PROTECTED] wrote: Hi Matt, I've been working on a skin which looks like the old Oracle skin from ADF. There's been some moderate interest in it on the user mailing list. It is based upon images/CSS from inside Trinidad. What this means is that it's licensed under the Apache license. So it can be freely used inside Trinidad. I've packaged into a separate deployable jar for one reason. 1) It makes distributing/managing it so very easy Drop it into your WEB-INF/lib and change your skin to oracle and off you go. Otherwise, I'm completely infavour of re-integrating it back into mainline Trinidad. Anyways, you can download it at http://www.engr.uvic.ca/~mrobinso/OracleSkin.jar Mark Matthias Wessendorf wrote: what does that mean ? finished up the packing for thje Oracle Skin ? Is it like taking the ADF Faces Skin and bundling it separate? If yes, I am pretty much sure that we cannot have it here in Trinidad, since that code belongs Oracle. Oracle donated *parts* of ADF Faces to the ASF, what is now called Trinidad. If the code is something you/your company wrote on your own which is similar to the *Oracle Skin*, I am fine with that. I'd suggest uploading it to a private homepage first. Danny Robinson does something similar with his *new* controll / component Thanks, Matthias On 1/30/07, Mark Robinson [EMAIL PROTECTED] wrote: Hi Guys, I've finished up the packing for the Oracle Skin. Is there a sandbox/upload region available? Mark -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: versioning
Sure, d'accord - just like the Tomcat folks do it, it doesn't make sense to keep the product versions fully at the spec or API versions. We should do the same for MyFaces and Tomahawk, by the way. regards, Martin On 2/4/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: resent, because went to PMC list. On 2/3/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi guys, currently our stuff has no real version number; only M1, which is almost nothing. I think we should name the current Trinidad stuff 1.0.0 and put the m1 (or incubator or incubating) to it, because of being incubator (for plugins and core). So something like: versionincubator-m1-SNAPSHOT/version would be: version1.0.0-incubating-SNAPSHOT/version The incubating I saw, when looking at OpenJPA. (of course w/o SNAPSHOT, after we do a release) For the JSF 1.2 branch I suggest to use the version 2.0 I think it doesn't make sense to follow the JSF version system in the version system of us. So, according to some blog entries, the next version for JSF (targeted for Java EE 6), will be called JSF 6. That would mean, if we stay tightly with their system we'd have a release or Trinidad 1.0 (mustn't it be 1.1 ??) Trinidad 1.2 Trinidad 6 which is really confusing (to me). So, to sum it up: -the current Trinidad stuff (based on JSF 1.1) will be 1.0.0 -the *future* stuff (based on JSF 1.2) will be the 2.0.0 stuff -In case of JSF 6, we simply have a 3.0.0. -using $version-incubating instead of $version-m1 Any comments ? -Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Vote] plugins m1 release (for JSF 1.1)
+1 regards, Martin On 1/13/07, Simon Lessard [EMAIL PROTECTED] wrote: +1 On 1/12/07, Adam Winer [EMAIL PROTECTED] wrote: +1. -- Adam On 1/12/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Yeah, sorry Grant. Forgot that PMCs from the sponsor (which is the Apache MyFaces crowd) is also good for a binding +1 Thanks for voting, since not all PPMC members voted On 1/12/07, Grant Smith [EMAIL PROTECTED] wrote: [X] +1 (Binding) for PPMC members only On 1/12/07, Bruno Aranda [EMAIL PROTECTED] wrote: [X] +1 (Binding) for PPMC members only On 12/01/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: [X] +1 (Binding) for PPMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, here is why -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Grant Smith -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Show me the Region!!!!
AFAIK, it's not included in the source here. Are you using facelets? Go with facelets templating, and you have much the functionality of af:region out of the box. regards, Martin On 12/1/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey all, I noticed in the Trinidad tag lib documentation that an af:region tag is supported. Yet on my relatively new version of the build, the region tag does not show up in the TLD. Anyone know if Regions are supported or not? If so, what tld do I need to import to get the tag definition? Scott -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Question] Copying code from MyFaces
Sure! we might do the same sometime ;) regards, Martin On 11/9/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Yay.. Thanks Martin. Martin Marinschek wrote: There is nothing offending in copying any of the classes over from MyFaces-Impl to Trinidad! regards, Martin On 11/8/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Guys, All arguments about the need for a common code package aside (yes, I will continue to champion this), Trinidad has the need to create container abstractions for some of our initialization services. We're basically going to use the external context to pass into these services because it's a familiar interface. The reason this needs to be done outside of the Faces arena is that these services MAY be kicked off from a filter if one is present because there were some usecases we just couldn't resolve in order to eliminate the need for the filter in order to work in the portal. Many of the usecases, however, can be written in a container-agnostic fashion and run from the portal. So here is my question. Is it bad for to copy come of the MyFaces code (namely the ExternalContext code) and move it into our packages, changing it as we need to. We cannot be dependent on the MyFaces Impl package (which is where this code currently exists) in order to maintain compatibility with the RI. Seems silly to rewrite these containers though. I figured I'd ask since both MyFaces and Trinidad are under the Apache Liscence. And yes, when/if we get a common package, we may be able to share this code but I'm on somewhat of a time limit. Scott -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Question] Copying code from MyFaces
There is nothing offending in copying any of the classes over from MyFaces-Impl to Trinidad! regards, Martin On 11/8/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Guys, All arguments about the need for a common code package aside (yes, I will continue to champion this), Trinidad has the need to create container abstractions for some of our initialization services. We're basically going to use the external context to pass into these services because it's a familiar interface. The reason this needs to be done outside of the Faces arena is that these services MAY be kicked off from a filter if one is present because there were some usecases we just couldn't resolve in order to eliminate the need for the filter in order to work in the portal. Many of the usecases, however, can be written in a container-agnostic fashion and run from the portal. So here is my question. Is it bad for to copy come of the MyFaces code (namely the ExternalContext code) and move it into our packages, changing it as we need to. We cannot be dependent on the MyFaces Impl package (which is where this code currently exists) in order to maintain compatibility with the RI. Seems silly to rewrite these containers though. I figured I'd ask since both MyFaces and Trinidad are under the Apache Liscence. And yes, when/if we get a common package, we may be able to share this code but I'm on somewhat of a time limit. Scott -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: new validator: dateRestrictionValidator
Great idea! regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Thanks Matthias. Okay, this is issue 258 https://issues.apache.org/jira/browse/ADFFACES-258 Thanks, Gab Matthias Wessendorf wrote: That would be a great improvement to all the inputDate / calendar (Tomahawk) components. I am also fine w/ the name. Opening an issue in jira does never hurt, when discussing an enhancement. :) -M On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Hi, I'd like to add a new validator. My proposed name is DateRestrictionValidator, other suggestions welcome. This would support attributes like: invalidMonths - example: dates in April are invalid invalidDaysOfWeek - example: Saturdays and Sundays are invalid invalidDays - example: 12-25-06 and 1-1-07 are invalid The exact api's will be discussed further as the implemenation is worked out. Does anyone oppose this or can I open an issue? Thanks, Gabrielle -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Formatting locale vs. translation locale
I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow automagically - without the developer really knowing. - First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. That's a very good point. If they only have US translations, the help uses US formatting, now we come along and actually use UK formatting, so the help is wrong. That does seem like a major problem for #2. Could we have a config setting to switch on #2, because I think #2 is very useful, but maybe they need to buy in, it's still a much less painful buy in than they have now with the converter 'locale' attribute Thanks, Gab 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be in (UK) dd-MM-, and I am actually getting (US) MM-dd-, that could cause me to miss my flight. --arjuna -- Adam --arjuna On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL
Re: Re: security issue w/ UIXEditableValue ?
Ok, this sounds reasonable. The annotations-stuff would of course be great. regards, Martin On 10/16/06, Adam Winer [EMAIL PROTECTED] wrote: Martin, You don't want the validator to be on the component with the values - once you've said that it's cross-component validation, that's just not the right place. For one thing, you're relying on all sorts of ordering and lifecycle processing that is not likely to be true going forward (see DynaFaces, for example). You can do a few things: - Create a parent component whose role in processing is to perform cross-component validations. - Use a phase listener and validation processing entirely external to the JSF component tree - Perform validation while committing (e.g., during the Invoke Application phase and an action) I kinda like the first one. What I'd really like to see is bean-level annotations describing validations that need to be run at that level (so, including cross-property validations), combined with the use of ELResolver/PropertyResolver magic to pick up on those bean-level validations (perhaps looking for bean-level annotations whenever a setValue() call is made). -- Adam On 10/16/06, Martin Marinschek [EMAIL PROTECTED] wrote: I totally agree, Matthias. But the question remains - how do you add a validation framework if not via adding a validator with the normal properties? And how will this framework be called in the case of a null value, if JSF doesn't let the validators (of this extended framework) run? regards, Martin On 10/15/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: for the required case I agree general no. we (jsf) should not invent the wheel of validation at all. it is pretty much common so that is should be handled in 303. I agree that some *cross value* validations can be handy. sometimes yeah, sometimes no. a framework (see sf.net) on top of faces is maybe fine for that. what's in swing for the case if field xyz is not submitted handle me like... ? or is it only in 296 ? -M On 10/14/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *; I've added a comment to http://issues.apache.org/jira/browse/MYFACES-1467 essentially saying that the null-value should never make a component skip validation. What do you think about that? regards, Martin On 10/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: hey I created ADFFACES-238 to keep track of it and we should have issues in jira for almost all commits. Since you agreed to this issue, I commit the change to the template tomorrow or so On 10/13/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I think you're right. I could have sworn that we were special-casing the required-validator; I even looked at the code in the old corporate repository, but this bug exists there. --arjuna On 10/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi please take a look at MYFACES-1467 which is also trure for UIXEditableValue.java's validate() method. But the spec 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.) the patch is basicly doing this instead: Object submittedValue = getSubmittedValue(); if (submittedValue == null !this.isRequired()) return; (it add's the !this.isRequired()) Why? See the descr. for the issue, since a man-in-the-middle tool can do some funny things. I saw David's demo this afternoon in ApacheCon Hackaton. I think the javadoc for jsf 1.1 and 1.2 should be changed... What do you think? -Matt -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: security issue w/ UIXEditableValue ?
I totally agree, Matthias. But the question remains - how do you add a validation framework if not via adding a validator with the normal properties? And how will this framework be called in the case of a null value, if JSF doesn't let the validators (of this extended framework) run? regards, Martin On 10/15/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: for the required case I agree general no. we (jsf) should not invent the wheel of validation at all. it is pretty much common so that is should be handled in 303. I agree that some *cross value* validations can be handy. sometimes yeah, sometimes no. a framework (see sf.net) on top of faces is maybe fine for that. what's in swing for the case if field xyz is not submitted handle me like... ? or is it only in 296 ? -M On 10/14/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *; I've added a comment to http://issues.apache.org/jira/browse/MYFACES-1467 essentially saying that the null-value should never make a component skip validation. What do you think about that? regards, Martin On 10/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: hey I created ADFFACES-238 to keep track of it and we should have issues in jira for almost all commits. Since you agreed to this issue, I commit the change to the template tomorrow or so On 10/13/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I think you're right. I could have sworn that we were special-casing the required-validator; I even looked at the code in the old corporate repository, but this bug exists there. --arjuna On 10/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi please take a look at MYFACES-1467 which is also trure for UIXEditableValue.java's validate() method. But the spec 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.) the patch is basicly doing this instead: Object submittedValue = getSubmittedValue(); if (submittedValue == null !this.isRequired()) return; (it add's the !this.isRequired()) Why? See the descr. for the issue, since a man-in-the-middle tool can do some funny things. I saw David's demo this afternoon in ApacheCon Hackaton. I think the javadoc for jsf 1.1 and 1.2 should be changed... What do you think? -Matt -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [vote] gabrielle crawford
+1 (binding). regards, Martin On 10/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: +1 (binding) Craig On 10/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey *, I'd like to start a vote for a new committer nominee Gabrielle Crawford Gabrielle Crawford has been very active on the adffaces-XXX lists. She has contributed several patches, improvments/new feature. I'd like to see Gabrielle becomming a Apache Trinidad committer. This vote has also been announced on the *public* general incubator list (see again [1]). Thanks, Matthias [1] http://incubator.apache.org/guides/ppmc.html -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [proposal] issue for a commit
+1 for applying this rule to all non-trivial commits. regards, Martin On 10/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 (binding) On 10/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi, in myfaces we have the sorta rule to create a jira issue for almost all commits. That has the benefit all of the ongoing *development* is more monitorable. I pretty much like that. Also it has the benefits for a thing called release note. just put all resolved jira numbers into the release note. What do you think? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces 1.1.4
Most of these probably result from trying to make sure Trinidad works well with the impl;) regards, Martin On 10/10/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: although my vote is not counted but that's a good idea just be aware that there are some incompatibilities between those versions. although I don't think those effect trinidad but it is so good to upgrade and be sure those incompatibilities will not affect trinidad On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: anyone mind to use myfaces 1.1.4 instead of 1.1.2? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Public API's not part of JSF
Hi Scott, we've had re-occuring discussions about a new commons-module. This would probably be good candidate for this. Additionally, I've still got to review a commit for a module by Shinsuke Sugaya, which is about portlet compatibility - maybe it would be good to put it there. regards, Martin On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Is there a place where we could store public API's that are not part of Faces in MyFaces? Would this be the shared-impl package? We'll likely need to support an interface to handle some of our filter functionality from a portlet. This interface would need be referenced by the MyFaces Bridge Portlet (in impl) and Trinidad Impl... Scott -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Tree2
Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). Additionally, the tree is doing a lot with respect to the markup of the component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer the data-model to the client (and maybe templates for each node-type), and then render the nodes on the client dynamically. Thoughts? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: JSF 1.2 branch of Trinidad
Yeah, as soon as Tomahawk 1.1.5 is done, there'll be quite some 1.2 work going on. I promise. regards, Martin On 9/28/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I am fine with that, also w/ using RI 1.2 instead of MyFaces. On the 1.2 is not much work going on. I hope that changes soon ;) -M On 9/28/06, Adam Winer [EMAIL PROTECTED] wrote: (Re-sending; it bounced the first time) My bosses at work are starting to request a JSF 1.2-based version of Trinidad, so I'd like to get started on that. What I'm thinking of: - A branch off the trunk (not on trunk) - Depending on the 1.2 RI, 'cause 1.2 isn't available yet - I'll file a JIRA issue for this. I wish it could be based on MyFaces, but 1.2 isn't there yet, and I wish I had time to help out on MyFaces 1.2, but I don't... :( My assumption is that this won't be the final 1.2 branch - instead of regular merges from trunk onto this branch, it'll probably be easier to create new 1.2 branches and merge the 1.2 work onto that. Or, to be more brief, I'm assuming that we won't bother having anyone check patches into both branches, at least for now - we'll just do 1.2 work on the 1.2 branch, and occasionally create new 1.2 branches to pull in all the latest patches. How's this sound? -- Adam -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: add tags for validateLength, validateLongRange, validateDoubleRange
+1 for Gabrielle's latest suggestion. Then the only thing I need to remember while writing the tag is that a messageDetail attribute starts with me, rest will be done by code-complete. regards, Martin On 9/27/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Adam Winer wrote: Well, as far as picking an API, I think the user is 99% important, the developer 1%. It's not that hard as a devloper to support multiple messages. So does that mean you like the Trin way of multiple detail attr's because the user shouldn't see a message that's flat out wrong? I agree that with something like convertNumber, there's not that much utility to having different properties for each, since it'd be incredibly rare for a user to set more than one on any one tag - you'll never have one convertNumber that is both a currency converter, and a percentage converter, etc. What I worry about a bit more is *forcing* that onto a base implementation, because you might have something like a validator that reports different messages depending on the error. Like a longRangeValidator that gave you too high, too low, etc. messages, depending on the value you enter. That would need multiple detail messages, potentially per validator. If we did keep it Trin's way it might be a good idea if the message attribute names were changed to have messageDetail first. That way they would be grouped together in the doc, and would have a similar name from one converter/validator to another, which would make them easier to find. For example here are a few attr's from various converter/validators: noMatchMessageDetail maximumMessageDetail minimumMessageDetail convertTimeMessageDetail would become messageDetailNoMatch messageDetailMaximum messageDetailMinimum messageDetailConvertTime Thanks, Gab -- Adam On 9/25/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I think you summed up both perfectly. That's also how I see it. As a JSF user, I'd prefer the tomahawk way -- only one attribute name to remember for every validator. The use case of having a customized per-input validator message is almost always going to encompass exactly one message string rather than the four possible for numberConverter. I don't see myself ever needing to make type variable. And as I said before, if I did that, it wouldn't take much to also make the message variable. As a JSF developer (MyFaces), it's far easier to maintain one ValidatorBase class that provides support for a single message attribute and have all validators inherit from it, rather than maintaining separate attributes for each individual validator. You can take a look at the current Tomahawk ValidatorBase class to see a good implementation of this (just committed last week, improving on the original design) that hides almost all of the message attribute handling code from the validator subclasses. On 9/22/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Thanks Mike. Here's some of the pros and cons of each, if you don't mind let's stick to the detail string for now. 1] current Trinidad way: have specific attributes for each detail PROS: usual case is that user binds each detail attr to a specific bundle key, the message won't be out of synch with the implementation no matter how other attr's are set. CONS: lots of attr's, inconsistent api 2] current Tomahawk way: support only detailMessage PROS: one attr, consistent api, and in most cases user will just bind to a specific bundle key CONS: it's error prone when you need to keep multiple attributes in synch to ensure proper behavior, and the value returned by the detailMessage needs to be in synch with other settings Do you agree with these? Anyone have any prefs? Thanks, Gabrielle Mike Kienenberger wrote: For Tomahawk, we've been supporting this as a message attribute for a few months. Earlier today, we changed it to detailMessage and summaryMessage attributes, with detailMessage replacing message. What about the option of using the same names between Tomahawk and Trinidad? I notice that numberConverter has 4 separate attributes even though only one of them would be used at a time. Is that really necessary? If you're going to make the type a value binding, you could make the message a value binding too. The other ones I glanced at only have one message attribute, even though the name varies from component to component. On 9/21/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Hi, If you look at the bottom of this page, you'll see Trin supports its own version of the RI converters, but not the RI validators: http://incubator.apache.org/adffaces/trinidad-api/tagdoc.html http://java.sun.com/javaee/javaserverfaces/1.1/docs/tlddocs/index.html Trin supports customizing the detail portion of a message on it's tags. See the doc here for the RI vs Trin
Re: add tags for validateLength, validateLongRange, validateDoubleRange
Ho-Ho - I never used the VI - I thought that was Adam's way of coding? regards, Martin On 9/27/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: same here Gab's last sug. On 9/27/06, Martin Marinschek [EMAIL PROTECTED] wrote: +1 for Gabrielle's latest suggestion. Then the only thing I need to remember while writing the tag is that a messageDetail attribute starts with me, rest will be done by code-complete. when did you get rid of the vi ? :) regards, Martin On 9/27/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Adam Winer wrote: Well, as far as picking an API, I think the user is 99% important, the developer 1%. It's not that hard as a devloper to support multiple messages. So does that mean you like the Trin way of multiple detail attr's because the user shouldn't see a message that's flat out wrong? I agree that with something like convertNumber, there's not that much utility to having different properties for each, since it'd be incredibly rare for a user to set more than one on any one tag - you'll never have one convertNumber that is both a currency converter, and a percentage converter, etc. What I worry about a bit more is *forcing* that onto a base implementation, because you might have something like a validator that reports different messages depending on the error. Like a longRangeValidator that gave you too high, too low, etc. messages, depending on the value you enter. That would need multiple detail messages, potentially per validator. If we did keep it Trin's way it might be a good idea if the message attribute names were changed to have messageDetail first. That way they would be grouped together in the doc, and would have a similar name from one converter/validator to another, which would make them easier to find. For example here are a few attr's from various converter/validators: noMatchMessageDetail maximumMessageDetail minimumMessageDetail convertTimeMessageDetail would become messageDetailNoMatch messageDetailMaximum messageDetailMinimum messageDetailConvertTime Thanks, Gab -- Adam On 9/25/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I think you summed up both perfectly. That's also how I see it. As a JSF user, I'd prefer the tomahawk way -- only one attribute name to remember for every validator. The use case of having a customized per-input validator message is almost always going to encompass exactly one message string rather than the four possible for numberConverter. I don't see myself ever needing to make type variable. And as I said before, if I did that, it wouldn't take much to also make the message variable. As a JSF developer (MyFaces), it's far easier to maintain one ValidatorBase class that provides support for a single message attribute and have all validators inherit from it, rather than maintaining separate attributes for each individual validator. You can take a look at the current Tomahawk ValidatorBase class to see a good implementation of this (just committed last week, improving on the original design) that hides almost all of the message attribute handling code from the validator subclasses. On 9/22/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Thanks Mike. Here's some of the pros and cons of each, if you don't mind let's stick to the detail string for now. 1] current Trinidad way: have specific attributes for each detail PROS: usual case is that user binds each detail attr to a specific bundle key, the message won't be out of synch with the implementation no matter how other attr's are set. CONS: lots of attr's, inconsistent api 2] current Tomahawk way: support only detailMessage PROS: one attr, consistent api, and in most cases user will just bind to a specific bundle key CONS: it's error prone when you need to keep multiple attributes in synch to ensure proper behavior, and the value returned by the detailMessage needs to be in synch with other settings Do you agree with these? Anyone have any prefs? Thanks, Gabrielle Mike Kienenberger wrote: For Tomahawk, we've been supporting this as a message attribute for a few months. Earlier today, we changed it to detailMessage and summaryMessage attributes, with detailMessage replacing message. What about the option of using the same names between Tomahawk and Trinidad? I notice that numberConverter has 4 separate attributes even though only one of them would be used at a time. Is that really necessary? If you're going to make the type a value binding, you could make the message a value binding too. The other ones I glanced at only have one message attribute, even though the name varies from
[OFFTOPIC] What I wish that JSF 2.0 would be like...
Hi there, Ed Burns, Jesse Alexander and me will be heading a discussion on what our users dreamed JSF 2.0 would be like - on friday, 2006/09/29, in Munich, at the Oktoberfest. So it's a good opportunity for both talking about JSF and drinking beer - probably the best of the world. We'll meet up in: http://www.weisses-brauhaus.de/ at 18:00 and if you're interested in coming, reply to this mail and I'll include you in the reservation. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Vote] Simon Lessard as a committer of the Trinidad Podling
+1 regards, Martin On 8/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 On 8/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey *, I'd like to start a vote for a new committer nominee Simon Lessard Simon Lessard has been very active on the adffaces-XXX lists. He has contributed several patches, improvments/new feature and provided documentation to our wiki. I'd like to see Simon becomming a Apache Trinidad committer. This vote has also been announced on the public general incubator list (see again [1]). Thanks, Matthias [1] http://incubator.apache.org/guides/ppmc.html -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Re: Company-specific branches
I totally agree with what Mike says here, and I do think that not only Oracle will profit of once-monthly stable branches. If there is something to say against a specific branch, we'll discuss it on the list, and we'll certainly find a solution. regards, Martin On 8/15/06, Adam Winer [EMAIL PROTECTED] wrote: On 8/15/06, Mike Kienenberger [EMAIL PROTECTED] wrote: As the saying goes, it's individuals not corporations that drive projects at the ASF, and if you, as an individual project manager, decide to make a milestone branch, why should this be an issue? We all make releases when we think we need them.I don't see the reason for needing the release as being all that important. True, I don't see why it does not to be an issue. I'm mostly trying to be cautious here and totally open about motivations etc... Whether Oracle does or does not need to use the branch seems irrelevent to me. True. So, if there was a branch that ever was only company XYZ people may touch this branch, that'd be wrong and bad. But milestone branches, open in general, maintained by committers (and it's not like committers are just going to be clamoring to push fixes into the trunk and lots of branches too), then there's no problem. I do rather like Craig's idea of fairly soon saying we've got a 1.0 branch, and getting that towards production - for everyone's sake - while we feel free to make larger changes - again, for everyone's sake - on the trunk. Now that the large-scale repackaging is done, I think merges will be relatively straightforward when there will be a need to commit on both trunk and a branch. -- Adam On 8/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/14/06, Adam Winer [EMAIL PROTECTED] wrote: On 8/14/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/14/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/14/06, Adam Winer [EMAIL PROTECTED] wrote: Hey all, For some of our internal, non-open source work here at Oracle, we're heavily depending on Trinidad (yay!). The catch is that, at certain points, we need a stable branch to build off of and apply only limited bug fixes so that internal work never gets destabilized. What I'd like to do is create branches in the Subversion repository for Trinidad code, with the following commitments: - No proprietary, non-Apache code will *ever* be checked in to such branches. - No work will happen on these branches that has not *first* been checked into trunk, with the possible exception of deeply hacky bug patches that wouldn't be wanted on a trunk. In other words, this will still be public work, and never even anything that could be construed as a fork in any way. Does this seem reasonable? Is it legit by Apache rules? All the alternatives I can think of are even less legit - e.g., we could make an internal copy of the source code, but that just reduces our exposure to the internal work and makes it less straightforward for us to hew to the true code on the trunk. I went back and asked what we (Sun) do with various artifacts we depend on (such as bits from Tomcat). Back in CVS days (where a branch was pretty expensive), we did some Sun-specific tags when we grabbed a snapshot, but then we put that code in an internal mirror repository and did our builds against that (plus any point fixes that were necessary). In an Subversion world where branches like this would be really cheap, I don't see a problem as long as the other committers are OK with it. But hey, I work for a company that might like to be able to do this too :-). It definitely seems like something worth asking on the Incubator general list (so that it eventually ends up as guidance for new podlings) but perhaps more broadly as well because it certainly matters for existing projects as well. I'll ping a couple of appropriate aliases so we can get broader feedback on this. OK, got some feedback, and it's going to be a -1 for two different categories of reasons: * Company private branches could potentially be construed as being in conflict with Apache's non-profit (501c3) status. * Private stabilization branches are considered by many folks to be bad engineering practice in the first place. See below for more on the advice of some of the Apache members. The advice on the practice side is to consider why we go through this kind of stabilization exercise in the first place. We don't want to get destabilized by changes in the trunk code (or in a Maven snapshot we depend on that suddenly changes underneath us). So, we try to control this change by a snapshot
Re: Charting Component
Well, with a unique prefix you are all set, yes! That's what I wanted to say - you need the client id and a unique prefix. Can you elaborate more on why org_apache_myfaces goes against the coding conventions of Java? Well, except for the underscore replacing the dot (dots are not possible, except you use a packaging system as e.g. dojo) regards, Martin On 7/18/06, venkata guddanti [EMAIL PROTECTED] wrote: Hi Martin, I am not sure I understand the first issue. I was planning to render the chart and its model using JS from the component renderer. So if the JS name includes the clientId (for e.g. trinidadChartid4) I was assuming that it would be unique enough on the page. I was suggesting that org_apache_myfaces_ is not a good prefix for JavaScript className since in Oracle for JavaScript we mostly follow the same coding conventions as Java. Regards, Venkata On 7/17/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Venkata, a unique component id and a unique method-name or variable name are two entirely different things. Imagine a chart component outside of any naming container, which gets the id chart set by the user. Whatever global variable you use will then be named according to your unique id, but that doesn't really mean the variable name is unique. If you use another chart component on the same page (yes, it's possible, there are several charting comps for JSF out there) the likelihood is great to run into name conflicts. Prepending everything with ADF is a better namespacing decision - the probability that something has the 3-letter combination ADF in its name is rather low. So if you properly define classnames which contain ADF, you should be all set. I still think that using the unique prefix you have in your domain (also used in your Java-package structure) is a much better prefix. You don't type a classname very often, and there's even code complete for this in some IDEs. Once more - method's shouldn't be global, and therefore don't need to be namespaced! There is really not much need for the use of global names except for classes and a very few variables. What is your reason for saying that org_apache_myfaces_ does not seem like a good prefix for class names? regards, Martin On 7/17/06, venkata guddanti [EMAIL PROTECTED] wrote: Hi Martin, Thanks for suggesting the namespace for JavaScript variables on the page. I was thinking that javascript variables rendered from the components are automatically unique if we suffix them with the clientId. I believe org_apache_myfaces_ does not seem like a good prefix for JavaScript class names. Is there a better prefix notation in myfaces for JavaScript class names? For e.g. In our RichClient framework built on top of trinidad all our javascript classes are prefixed with ADF Regards, Venkata On 7/17/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Venkata, the general rule in MyFaces is to prefix with: org_apache_myfaces_ regards, Martin On 7/17/06, venkata guddanti [EMAIL PROTECTED] wrote: Hi Martin, The global variable is only in the test page. The rendering logic is in Chart.js. I plan to make this logic namespace compliant. Currently it is using chart as a namespace. For e.g. chartAssert etc., Chart is the base class for all the other chart types. I believe I will change the namespace to something like: trinidadChart. I would appreciate any other comments regarding the prototype. Please also keep in mind that this code is still rough. I have to make a pass through it to clean it up. For e.g. I have private variables in the base class that I am using in the derived classes. I still have few weeks of work before I can start integrate with the trinidad and PPR framework as I have a day job with Oracle :). Here are some of the important things that I have left regarding the charting: - Animation support. - Better Labeling support - Tooltips I will ask Matthias to put another version on the server as I am just about ready to integrate. Regards, Venkata On 7/16/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, from a short look, I think you'll have to make your javascript comply better with object oriented principles. e.g. global variable: var chart (name is not namespaced, global is not too good anyways, etc.) regards, Martin On 7/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Martin, check http://people.apache.org/~matzew/venkata/ There I deployed the prototype from Venkata. -Matthias On 7/16/06, Martin Marinschek [EMAIL PROTECTED] wrote: May I ask about the underlying JavaScript? Do you use global method names, or object oriented javascript? How about
Re: Charting Component
Hi Venkata, the general rule in MyFaces is to prefix with: org_apache_myfaces_ regards, Martin On 7/17/06, venkata guddanti [EMAIL PROTECTED] wrote: Hi Martin, The global variable is only in the test page. The rendering logic is in Chart.js. I plan to make this logic namespace compliant. Currently it is using chart as a namespace. For e.g. chartAssert etc., Chart is the base class for all the other chart types. I believe I will change the namespace to something like: trinidadChart. I would appreciate any other comments regarding the prototype. Please also keep in mind that this code is still rough. I have to make a pass through it to clean it up. For e.g. I have private variables in the base class that I am using in the derived classes. I still have few weeks of work before I can start integrate with the trinidad and PPR framework as I have a day job with Oracle :). Here are some of the important things that I have left regarding the charting: - Animation support. - Better Labeling support - Tooltips I will ask Matthias to put another version on the server as I am just about ready to integrate. Regards, Venkata On 7/16/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, from a short look, I think you'll have to make your javascript comply better with object oriented principles. e.g. global variable: var chart (name is not namespaced, global is not too good anyways, etc.) regards, Martin On 7/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Martin, check http://people.apache.org/~matzew/venkata/ There I deployed the prototype from Venkata. -Matthias On 7/16/06, Martin Marinschek [EMAIL PROTECTED] wrote: May I ask about the underlying JavaScript? Do you use global method names, or object oriented javascript? How about namespacing? regards, Martin On 7/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 7/13/06, venkata guddanti [EMAIL PROTECTED] wrote: Hi Matthias, I would prefer to develop it as a trinidad component. I am more familiar with this environment and I have never looked at MyFaces codebase. I am also not sure if MyFaces sandbox supports AJAX. Hi venkata, ok; stay with Trinidad, but make sure the renderer is Faces Major. I'll make it *compatible* with Tomahawk / MyFaces Shared. And yes, the sandbox supports AJAX. -Matthias Plus Oracle pays by bills :) Regards, Venkata On 7/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: In that case we have *no* IP issue. I think this component should be developed under the MyFaces sandbox. That can also be a play ground for a more *common* base of MyFaces/Trinidad. -Matthias On 7/13/06, venkata guddanti [EMAIL PROTECTED] wrote: I wrote all the JavaScript myself. On 7/13/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 7/13/06, venkata guddanti [EMAIL PROTECTED] wrote: I wrote this from scratch and only have a dependency on browser javascript and SVG. I learnt that apache.org does not accept images. So here are links to my charting images: http://picasaweb.google.com/venkata.guddanti/Charting/ When you say that it has a dependency on browser javascript, do you mean that it uses javascript that you wrote, or do you mean that it depends on javascript that someone else wrote? If the second, we'll need to consider the license for that javascript. -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Charting Component
Hi Venkata, a unique component id and a unique method-name or variable name are two entirely different things. Imagine a chart component outside of any naming container, which gets the id chart set by the user. Whatever global variable you use will then be named according to your unique id, but that doesn't really mean the variable name is unique. If you use another chart component on the same page (yes, it's possible, there are several charting comps for JSF out there) the likelihood is great to run into name conflicts. Prepending everything with ADF is a better namespacing decision - the probability that something has the 3-letter combination ADF in its name is rather low. So if you properly define classnames which contain ADF, you should be all set. I still think that using the unique prefix you have in your domain (also used in your Java-package structure) is a much better prefix. You don't type a classname very often, and there's even code complete for this in some IDEs. Once more - method's shouldn't be global, and therefore don't need to be namespaced! There is really not much need for the use of global names except for classes and a very few variables. What is your reason for saying that org_apache_myfaces_ does not seem like a good prefix for class names? regards, Martin On 7/17/06, venkata guddanti [EMAIL PROTECTED] wrote: Hi Martin, Thanks for suggesting the namespace for JavaScript variables on the page. I was thinking that javascript variables rendered from the components are automatically unique if we suffix them with the clientId. I believe org_apache_myfaces_ does not seem like a good prefix for JavaScript class names. Is there a better prefix notation in myfaces for JavaScript class names? For e.g. In our RichClient framework built on top of trinidad all our javascript classes are prefixed with ADF Regards, Venkata On 7/17/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Venkata, the general rule in MyFaces is to prefix with: org_apache_myfaces_ regards, Martin On 7/17/06, venkata guddanti [EMAIL PROTECTED] wrote: Hi Martin, The global variable is only in the test page. The rendering logic is in Chart.js. I plan to make this logic namespace compliant. Currently it is using chart as a namespace. For e.g. chartAssert etc., Chart is the base class for all the other chart types. I believe I will change the namespace to something like: trinidadChart. I would appreciate any other comments regarding the prototype. Please also keep in mind that this code is still rough. I have to make a pass through it to clean it up. For e.g. I have private variables in the base class that I am using in the derived classes. I still have few weeks of work before I can start integrate with the trinidad and PPR framework as I have a day job with Oracle :). Here are some of the important things that I have left regarding the charting: - Animation support. - Better Labeling support - Tooltips I will ask Matthias to put another version on the server as I am just about ready to integrate. Regards, Venkata On 7/16/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, from a short look, I think you'll have to make your javascript comply better with object oriented principles. e.g. global variable: var chart (name is not namespaced, global is not too good anyways, etc.) regards, Martin On 7/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Martin, check http://people.apache.org/~matzew/venkata/ There I deployed the prototype from Venkata. -Matthias On 7/16/06, Martin Marinschek [EMAIL PROTECTED] wrote: May I ask about the underlying JavaScript? Do you use global method names, or object oriented javascript? How about namespacing? regards, Martin On 7/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 7/13/06, venkata guddanti [EMAIL PROTECTED] wrote: Hi Matthias, I would prefer to develop it as a trinidad component. I am more familiar with this environment and I have never looked at MyFaces codebase. I am also not sure if MyFaces sandbox supports AJAX. Hi venkata, ok; stay with Trinidad, but make sure the renderer is Faces Major. I'll make it *compatible* with Tomahawk / MyFaces Shared. And yes, the sandbox supports AJAX. -Matthias Plus Oracle pays by bills :) Regards, Venkata On 7/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: In that case we have *no* IP issue. I think this component should be developed under the MyFaces sandbox. That can also be a play ground for a more *common* base of MyFaces/Trinidad. -Matthias On 7/13/06, venkata guddanti [EMAIL PROTECTED
Re: [Proposal] JavaScript Popup Calendar
Prepare it for Trinidad - I'll have a look at it when it's finished, and will take it over for tomahawk if I like it! regards, Martin On 7/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 7/14/06, Dan Robinson [EMAIL PROTECTED] wrote: However, I'm lost in the to-and-fro's of podling, merging tomahawk, etc. Was anything decided? Where do you want this stuff to go, or do we work alone until we have something ready? not yet. The merge is not a from day to day thing. For now, we don't have a solution for that stuff. Matt D. On 7/8/06, Adam Winer [EMAIL PROTECTED] wrote: Does the Dojo datepicker support internationalization? This is a must-have. I tried switching my browser to French but it still came up in English. Also, I'd be -1 on adding something if it couldn't support Trinidad skinning. -- Adam On 7/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: How do you call this ? http://dojotoolkit.org/~dylan/dojo/tests/widget/demo_DatePicker.html http://dojotoolkit.org/%7Edylan/dojo/tests/widget/demo_DatePicker.html On 7/8/06, Martin Marinschek [EMAIL PROTECTED] wrote: yeah, dojo would be great - but dojo doesn't have a popup calendar so far! regards, Martin On 7/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: cool to hear martin, what's up, should we both take a look at dojo? (the xml way)? On 7/7/06, Martin Marinschek [EMAIL PROTECTED] wrote: One thing more - I don't like the javascript codebase of the current tomahawk calendar, just to put this into the discussion. So if someone comes up with a better solution (and the same or better functionality) I'll happily put this component into tomahawk as well. regards, Martin On 7/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: More... at ApacheCon Bernd and me also discussed about, what's with the tobago code base. Stuff like upload can be *unified* for all these three libs. -Matthias On 7/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Mike On 7/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Moving to dev. good idea Well, not to be a pain about it, but the inability of some users to use a released product like Tomahawk shouldn't be driving the development decisions of a podling. sure! The need to have a popup calendar looks like a perfect trial run of merging the two code bases, and I'd hate to see someone go out and reinvent the popup calendar wheel yet another time when we've already got two or three of them. sure, popup cal. is just a *simple* example of that. We have a wiki for identifing some task. Feel free to add content. (see [1]). Realistically, merging the two is probably going to be more a matter of porting Tomahawk components over to Trinidad than the other way around, I'm guessing, so maybe I'm arguing over semantics. Yeah, sorta. The Trinidad podling for instance has already *buid-in*support for Facelets. Tomahawk has also some goodies. This task (merging) won't be a short one (IMO) -Matt [1] http://wiki.apache.org/myfaces/ADF_Faces/Identify_components_to_merge_into_Tomahawk_Shared On 7/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey Mike, yes that is the goal. but for some reasons user's won't / can't use Tomahawk (or MyFaces) in their production. I think that was the reason for this thread. Creating a custom one on top of the Trinidad Podling is ok for me. For the tomahawk stuff, we should take a look at Dojo ([1]). On the ApacheCon I saw that they have now xml namespaces, means dojo:wiget ... / instead of *hacking* JS. I know some projects, that are not allowed to use MyFaces; they stick with IBM or the RI. -Matthias [1] http://dojotoolkit.org/~dylan/dojo/tests/widget/demo_DatePicker.htmlhttp://dojotoolkit.org/%7Edylan/dojo/tests/widget/demo_DatePicker.html On 7/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Could someone refresh my memory? Was the eventual goal to merge Trinidad and Tomahawk? If so, I think creating Yet Another Popup Calendar rather than making the existing tomahawk popup calendars play nice with Trinidad is a step in the wrong direction. However, I could be off-base on the eventual goal for these two libraries
Family of ADF-Faces form
Hi *,
can anybody tell me what the family of the ADF Faces form was before
the rename to
org.apache.myfaces.adf.Form
in a quest for compatibility, I'd like to add the old ADF Faces form
family to be checked for in the following code snippet.
regards,
Martin
public static FormInfo findNestingForm(UIComponent uiComponent,
FacesContext facesContext)
{
UIComponent parent = uiComponent.getParent();
while (parent != null
(!FORM_COMPONENT_FAMILY.equals(parent.getFamily())
!TRINIDAD_FORM_COMPONENT_FAMILY.equals(parent.getFamily(
{
parent = parent.getParent();
}
if (parent != null)
{
//link is nested inside a form
String formName = parent.getClientId(facesContext);
return new FormInfo(parent, formName);
}
return null;
}
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Charting Component
May I ask about the underlying JavaScript? Do you use global method names, or object oriented javascript? How about namespacing? regards, Martin On 7/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 7/13/06, venkata guddanti [EMAIL PROTECTED] wrote: Hi Matthias, I would prefer to develop it as a trinidad component. I am more familiar with this environment and I have never looked at MyFaces codebase. I am also not sure if MyFaces sandbox supports AJAX. Hi venkata, ok; stay with Trinidad, but make sure the renderer is Faces Major. I'll make it *compatible* with Tomahawk / MyFaces Shared. And yes, the sandbox supports AJAX. -Matthias Plus Oracle pays by bills :) Regards, Venkata On 7/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: In that case we have *no* IP issue. I think this component should be developed under the MyFaces sandbox. That can also be a play ground for a more *common* base of MyFaces/Trinidad. -Matthias On 7/13/06, venkata guddanti [EMAIL PROTECTED] wrote: I wrote all the JavaScript myself. On 7/13/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 7/13/06, venkata guddanti [EMAIL PROTECTED] wrote: I wrote this from scratch and only have a dependency on browser javascript and SVG. I learnt that apache.org does not accept images. So here are links to my charting images: http://picasaweb.google.com/venkata.guddanti/Charting/ When you say that it has a dependency on browser javascript, do you mean that it uses javascript that you wrote, or do you mean that it depends on javascript that someone else wrote? If the second, we'll need to consider the license for that javascript. -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Proposal] JavaScript Popup Calendar
yeah, dojo would be great - but dojo doesn't have a popup calendar so far! regards, Martin On 7/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: cool to hear martin, what's up, should we both take a look at dojo? (the xml way)? On 7/7/06, Martin Marinschek [EMAIL PROTECTED] wrote: One thing more - I don't like the javascript codebase of the current tomahawk calendar, just to put this into the discussion. So if someone comes up with a better solution (and the same or better functionality) I'll happily put this component into tomahawk as well. regards, Martin On 7/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: More... at ApacheCon Bernd and me also discussed about, what's with the tobago code base. Stuff like upload can be *unified* for all these three libs. -Matthias On 7/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Mike On 7/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Moving to dev. good idea Well, not to be a pain about it, but the inability of some users to use a released product like Tomahawk shouldn't be driving the development decisions of a podling. sure! The need to have a popup calendar looks like a perfect trial run of merging the two code bases, and I'd hate to see someone go out and reinvent the popup calendar wheel yet another time when we've already got two or three of them. sure, popup cal. is just a *simple* example of that. We have a wiki for identifing some task. Feel free to add content. (see [1]). Realistically, merging the two is probably going to be more a matter of porting Tomahawk components over to Trinidad than the other way around, I'm guessing, so maybe I'm arguing over semantics. Yeah, sorta. The Trinidad podling for instance has already *buid-in*support for Facelets. Tomahawk has also some goodies. This task (merging) won't be a short one (IMO) -Matt [1] http://wiki.apache.org/myfaces/ADF_Faces/Identify_components_to_merge_into_Tomahawk_Shared On 7/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey Mike, yes that is the goal. but for some reasons user's won't / can't use Tomahawk (or MyFaces) in their production. I think that was the reason for this thread. Creating a custom one on top of the Trinidad Podling is ok for me. For the tomahawk stuff, we should take a look at Dojo ([1]). On the ApacheCon I saw that they have now xml namespaces, means dojo:wiget ... / instead of *hacking* JS. I know some projects, that are not allowed to use MyFaces; they stick with IBM or the RI. -Matthias [1] http://dojotoolkit.org/~dylan/dojo/tests/widget/demo_DatePicker.html On 7/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Could someone refresh my memory? Was the eventual goal to merge Trinidad and Tomahawk? If so, I think creating Yet Another Popup Calendar rather than making the existing tomahawk popup calendars play nice with Trinidad is a step in the wrong direction. However, I could be off-base on the eventual goal for these two libraries. On 7/7/06, Adam Winer [EMAIL PROTECTED] wrote: It would definitely be of interest! (IMO, it would need to handle internationalization and localization - I'd like to keep Trinidad consistent in this regard.) -- Adam On 7/7/06, Dan Robinson [EMAIL PROTECTED] wrote: Just a quick prompt to see if there is interest in such a feature. We may have capacity to contribute. I see this being rendered in 'inaccessible' mode only, perhaps instead of the window'ed calendar - thoughts. On 6/29/06, Dan Robinson [EMAIL PROTECTED] wrote: Thanks Ernst. We're really trying not to stray from Trinidad as a core library. However, I do like the look of the Tomahawk version, so that would make a very good start. I guess I'm looking for guidance as to where this would fit and how it would be configured - and indeed if people think Trinidad needs one! On 6/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: There is a calendar with a JS-Popup mode in the tomahawk-component library. Take a look at: http://www.irian.at/myfaces/calendar.jsf Maybe you can use this one, or at least if you want to implement something similar in trinidad learn from this one. regards Ernst On 6/29/06, Dan Robinson [EMAIL PROTECTED] wrote: Would there be interest in a 3rd calendar mode whereby it popsup a JavaScript calendar, rather than just the inline and windowed versions? If so
Re: [Proposal] JavaScript Popup Calendar
One thing more - I don't like the javascript codebase of the current tomahawk calendar, just to put this into the discussion. So if someone comes up with a better solution (and the same or better functionality) I'll happily put this component into tomahawk as well. regards, Martin On 7/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: More... at ApacheCon Bernd and me also discussed about, what's with the tobago code base. Stuff like upload can be *unified* for all these three libs. -Matthias On 7/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Mike On 7/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Moving to dev. good idea Well, not to be a pain about it, but the inability of some users to use a released product like Tomahawk shouldn't be driving the development decisions of a podling. sure! The need to have a popup calendar looks like a perfect trial run of merging the two code bases, and I'd hate to see someone go out and reinvent the popup calendar wheel yet another time when we've already got two or three of them. sure, popup cal. is just a *simple* example of that. We have a wiki for identifing some task. Feel free to add content. (see [1]). Realistically, merging the two is probably going to be more a matter of porting Tomahawk components over to Trinidad than the other way around, I'm guessing, so maybe I'm arguing over semantics. Yeah, sorta. The Trinidad podling for instance has already *buid-in*support for Facelets. Tomahawk has also some goodies. This task (merging) won't be a short one (IMO) -Matt [1] http://wiki.apache.org/myfaces/ADF_Faces/Identify_components_to_merge_into_Tomahawk_Shared On 7/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey Mike, yes that is the goal. but for some reasons user's won't / can't use Tomahawk (or MyFaces) in their production. I think that was the reason for this thread. Creating a custom one on top of the Trinidad Podling is ok for me. For the tomahawk stuff, we should take a look at Dojo ([1]). On the ApacheCon I saw that they have now xml namespaces, means dojo:wiget ... / instead of *hacking* JS. I know some projects, that are not allowed to use MyFaces; they stick with IBM or the RI. -Matthias [1] http://dojotoolkit.org/~dylan/dojo/tests/widget/demo_DatePicker.html On 7/7/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Could someone refresh my memory? Was the eventual goal to merge Trinidad and Tomahawk? If so, I think creating Yet Another Popup Calendar rather than making the existing tomahawk popup calendars play nice with Trinidad is a step in the wrong direction. However, I could be off-base on the eventual goal for these two libraries. On 7/7/06, Adam Winer [EMAIL PROTECTED] wrote: It would definitely be of interest! (IMO, it would need to handle internationalization and localization - I'd like to keep Trinidad consistent in this regard.) -- Adam On 7/7/06, Dan Robinson [EMAIL PROTECTED] wrote: Just a quick prompt to see if there is interest in such a feature. We may have capacity to contribute. I see this being rendered in 'inaccessible' mode only, perhaps instead of the window'ed calendar - thoughts. On 6/29/06, Dan Robinson [EMAIL PROTECTED] wrote: Thanks Ernst. We're really trying not to stray from Trinidad as a core library. However, I do like the look of the Tomahawk version, so that would make a very good start. I guess I'm looking for guidance as to where this would fit and how it would be configured - and indeed if people think Trinidad needs one! On 6/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: There is a calendar with a JS-Popup mode in the tomahawk-component library. Take a look at: http://www.irian.at/myfaces/calendar.jsf Maybe you can use this one, or at least if you want to implement something similar in trinidad learn from this one. regards Ernst On 6/29/06, Dan Robinson [EMAIL PROTECTED] wrote: Would there be interest in a 3rd calendar mode whereby it popsup a JavaScript calendar, rather than just the inline and windowed versions? If so, is there one out there that people would like to see as the basis on which to build? Danny -- Matthias Wessendorf futher stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf futher stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf futher stuff: blog:
Re: FW: Discussion concerning optionnal init parameter for Dialog:
You got a spam mail asking you to subscribe to the adf-faces list? wow! regards, Martin On 7/5/06, Rick Rodriguez [EMAIL PROTECTED] wrote: If you could send me the link, or guide me to where i can find the link, i would greatly appreciate it. I signed on to the email list from a spam mail i recieved, thinking it would be nice to learn more about faces. However, it seems to be over my head at this time in my carreer. Any help with the unsubscribe would be appreciated. Thanks for you help in advance. Rick Rodriguez GIS Administration Santa Clara Valley Water District 5750 Almaden Expressway San Jose, CA 95118 408.265.2607 x2781 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Wednesday, July 05, 2006 12:03 PM To: adffaces-dev@incubator.apache.org Subject: Re: FW: Discussion concerning optionnal init parameter for Dialog: hey you should do that on your own. it is simple to unsubscribe ... On 7/5/06, Rick Rodriguez [EMAIL PROTECTED] wrote: Please remove me from this list. Thank you very much.. Rick Rodriguez GIS Administration Santa Clara Valley Water District 5750 Almaden Expressway San Jose, CA 95118 408.265.2607 x2781 [EMAIL PROTECTED] -Original Message- From: Cosma Colanicchia [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 8:57 AM To: adffaces-dev@incubator.apache.org Subject: Re: Discussion concerning optionnal init parameter for Dialog: Hi Pierre, it has be already done on the other side, so don't know if it is really required. Cosma 2006/7/5, [EMAIL PROTECTED] [EMAIL PROTECTED]: Hi, the subject adressed below is concerning this JIRA entry : http://issues.apache.org/jira/browse/ADFFACES-2 While looking to add this feature, I came to an halt concerning where should the new init parameter be put? As the JIRA request implies, it is concerning ADF Dialog and thus I was thinking it would be a good idea to add the new key in adf-faces-config.xml. However it will obviously requires more files to be modified than if the key is added in context-param of the web.xml. Any opinion where this new parameter should be put, that is between adf-faces-config.xml or web.xml ? -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Proposal] inhibiting css properties in skin definition file
+1 for the proposal in a whole
+1 for using inhibit - I like it more than reset or null
suggestion for ca new prefix-name: changing ora to oam (org apache myfaces)
regards,
Martin
On 6/24/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
I have another skinning proposal. This is a useful feature that is in
xss that I think we should port to skinning css. It is the css property
resetting feature.
A bit of background first. Trinidad defines a base skin. We call this
skin 'simple'. It defines basic, simple css properties for the Trinidad
components. An application developer can create a skin, and this
automatically extends the simple skin. Think of the simple skin as a
base class in Java. You can extend one skin from another, but they are
all derived from the base skin.
When a skin extends the base skin, it is ADDING style properties to the
base skin's style properties.
Let's say the base skin defines the font-size for the
af|inputText::label selector. This means that your skin will inherit
this font. Your skin can redefine font-size, and put a new font-size
instead. But currently, you can't say, I don't want any font-size
specified on af|inputText::label.
I'm proposing that we come up with a skinning syntax that allows the
person writing a skin to do this.
We have this feature in the .xss syntax. In .xss, you'd do this:
style name=foo resetProperties=true/
or to reset one property, you'd do this:
style name=foo
property name=font-size/
/style
How could we do this in css-syntax?
One proposal is to add a special property like our '-ora-rule-ref'
property. (by the way, we'll need another discussion on whether to
change the -ora- prefix, and what to change it to).
Here is a proposal:
.foo {-ora-inhibit: all}
.bar {-ora-inhibit: text-align font-size color} // inhibit/reset/null
out these specific properties
Let me know what you think.
Thanks,
Jeanne
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: PPR - client-side
.) Substitute the submit-function of the main-Form to use submitAJAX instead 4.) if a button is pressed or a value changed that would lead to a submit of the mainForm, submitAJAX checks based on getZonesToReload if an AJAXRequest is to be done. if not the form is submitted as usual. 5.)If it is an AJAX request a post-request is build with all parameter/value pairs of the form elements + -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its an AJAX-Request -aazones=id1,id2 - Tell which zones need to be updated 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses the HTML in the Response to extract the specified zones (big disadvantage the whole component tree gets rendered internally). 7.)HTML-Code of the zones is packed into xml-tags with the name of the zones as attribute and send back to the client 8.)Client parses the response and sets element.innerHTML of the zone-span-elements with the contents from the response What I like in this approach is the Javascript-Code that generates the Post-Request and the Code that parses the response and updates the DOM. The Server Side is pretty ugly. I would prefer to find a way to invoke only the affected components which I think should also make it faster. I haven't yet completly understood how trinidad handles this, but I think they have the cleaner solution for the server-side. What I also don't like is the JS-Code you have to write in your JSPs (calling substitueSubmitFunction, defining getZonesToReload, ..) In this point I would much prefer something like the partialTriggers-Attribute in trinidad. The thing is you have to define 1. which elements are to be reloaded by AJAX 2. which elements trigger those reloads I could also think of a listener-Component that can be added to the to-be-updated-elements and specify by which components those updates are triggered (which is pretty much the other way around compared to trinidad). I'm not yet completly shure whats the optimal approach for this, but I'll start with writing a s:panelGroup which supports a partialTriggers-Attribute that takes ids of radio-buttons (whith onchange=submit()). For a start I will integrate this with AJAX-Anywhere to have something to try the different approches for the JSP-Part. Just for playing around whith it. If anyone is interested I'll try to make this online available once I'm done. Suggestions, Objections, Ideas and advices are very welcome :-) regards Ernst On 6/15/06, Adam Winer [EMAIL PROTECTED] wrote: I'd be thrilled! For background, PPR was developed back before XMLHttp existed. Back then, the only decent way to communicate to the server was via hidden iframes. That solution has *a lot* of problems - for example, no decent way to handle errors, and the document that comes back can get parsed as HTML, which leads to some ugliness with handling Javascript, etc.. It was a great choice for the time, but it's showing its age, and there's better technologies Swapping out the client-side piece for an XMLHttpRequest-based submission, with probably a few tweaks to the syntax delivered by the PPR ResponseWriter, would give us a much more robust solution, and would be a great isolated task. I'd be more than happy to point anyone tackling this in the right directions. -- Adam On 6/14/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, Ernst Fastl - in his SoC beginning review - has worked on comparing the different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad, and some of the Avatar approach. What he's come up with so far is that he really likes the server-side integration of Trinidad, especially the syntax of integrating it in the view definition - not so much the client-side portion of it for doing PPR. Would you be happy with work being done on the client side portion of the PPR interaction in Trinidad in the SoC project? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Proposal] skinning platform, agent, and language features
Catalin, I'm +1 on any changes you want to do on the existing framework, but keep insync with Trinidad's skinning developers (like Jeanne) so that all of this is used for Trinidad as well - keep in mind that our ultimate goal here is merging together the different approaches, laying the base for making the component sets compliant to each other. New features are great, but only if they end up in both sides of the great divide. @Tobago developers: if anyone is interested - Catalin has looked through the skinning approaches, and Trinidad's deemed him best for implementing the skinning portion of Tomahawk. If anyone wants to help out with getting this compliant with the Tobago skinning, this would be great! regards, Martin On 6/15/06, Adam Winer [EMAIL PROTECTED] wrote: Catalin, Sounds awesome! Looking forward to it. If there's a good way to use less CSS 3 syntax but keep the functionality, I'm all for it. -- Adam On 6/14/06, Catalin Kormos [EMAIL PROTECTED] wrote: Hi Adam, Sorry if this was confusing, i certainly wouldn't want to write a pretty new framework for skinning, and this to be used only by Tomahawk. As Martin mentioned we did compare existing approaches besides Trinidad's, like the one from Tobago and I also took a look at Exadel Visual Component Platform's skinning. As far as i know these are all the current approaches for JSF and Trinidad's is the one choosed to be based on, all the features it offers are realy nice and there is room for more, like what Jeanne would like to implement, right? The goal is to work on making the Trinidad's skinning framework become the skinning framework for MyFaces. There are things to be changed though. Like going all the way with CSS, and not use XSS for the base skins, allow skins to extend each other and not just a base skin, and allow @import rules to be used. The most important changes i was planning to do are related to parsing and merging the CSS files. Right now, Trinidad uses CSS3 syntax for component selectors, and has it's own way of parsing that syntax. What i want to do is use a standard CSS2 compliant parser (an implementation of SAC, http://www.w3.org/Style/CSS/SAC/), with minimal extensions, for example to recognize @agent rules, and have an internal model based on DOM Level 2 Style specifications ( http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/). This could determine also changing the naming of the component selectors to use CSS2 valid syntax from the beginning but would eliminate the transformation of CSS3 syntax into CSS2 syntax that currently occurs. I would certainly appreciate your feedback on these plans, and help to find to the best approach for bringing Trinidad skinning framework into the overall MyFaces world. Regards, Catalin On 6/14/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Adam, inspired means it will be based on the ADF Faces skinning framework. We evaluated Tobago's and Trinidad's thing, and we decided for the Trinidad way. Whatever extensions we write, will go to both Trinidad and Tomahawk (the definitive goal would be a common module we could both base upon). regards, Martin On 6/14/06, Adam Winer [EMAIL PROTECTED] wrote: Catalin, One quick comment: I don't see a reason to write a skinning framework inspired by the Trinidad skinning. Trinidad is part of MyFaces; why not work on taking the Trinidad skinning framework and bringing it into the overall MyFaces world? -- Adam On 6/14/06, Catalin Kormos [EMAIL PROTECTED] wrote: Hi there, I just want to say that it sounds to me like a very good ideea, having the same skin take care of browsers incompatibilities for example, rather than having different skins take care of that, with need of user intervention; i'm working on the future skinning framework for MyFaces (at least i hope it will become that), which is very much inspired by the current state of the ADF Faces skinning. It's going to be done during the Google's SoC program btw. Would be ok if i take some inspiration from this too? :) A concern of mine would be about the :lang pseudo selector. Maybe this one i didn't get quite right, but wouldn't this interfere with the standard usage of the :lang pseudo selector, for styling components that renderer their own different lang attribute value, maybe on the same page? this might not be the case for ADF Faces components though. Regards, Catalin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
PPR - client-side
Hi *, Ernst Fastl - in his SoC beginning review - has worked on comparing the different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad, and some of the Avatar approach. What he's come up with so far is that he really likes the server-side integration of Trinidad, especially the syntax of integrating it in the view definition - not so much the client-side portion of it for doing PPR. Would you be happy with work being done on the client side portion of the PPR interaction in Trinidad in the SoC project? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Vote] missing name for the ADF donation
Gold wasn't intended to stand alone - instead to be used in conjunction with MyFaces: MyFaces Gold (like jakarta-commons) regards, Martin On 6/8/06, Martin Cooper [EMAIL PROTECTED] wrote: +1 for Trinidad. -1 for Gold. The term Gold is often used as an abbreviation for Gold Master, meaning the final release of a product. That in itself could be confusing. However, given that many people refer to Apache HTTPD as simply Apache, the term Apache Gold could also be used to refer to a final release of the web server. Let's just avoid any potential confusion, and not use the term Gold to refer to ADF Faces. -- Martin Cooper On 6/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, as pointed out in [1] there is still a name missing for the ADF donation. Lot's of names have been suggested through the community. Thanks. I filtered some names that are already take by a company name or a software name. The list of possible name is long. Please take a look and vote for ONE name. Gold Foxberry Chagall Chameleon Tofu Tonga Togo Toscanini Trinidad grapefruit shines Banten toolkit/toolbox/toolshed Torino Thanks, Matthias [1] http://issues.apache.org/jira/browse/ADFFACES-6 -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Vote] missing name for the ADF donation
We've had an additional name proposed while we were voting - should we still take it in or not? Zuku for some japanese name for steel and the german Zukunft=future regards, Martin On 6/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, as pointed out in [1] there is still a name missing for the ADF donation. Lot's of names have been suggested through the community. Thanks. I filtered some names that are already take by a company name or a software name. The list of possible name is long. Please take a look and vote for ONE name. Gold Foxberry Chagall Chameleon Tofu Tonga Togo Toscanini Trinidad grapefruit shines Banten toolkit/toolbox/toolshed Torino Thanks, Matthias [1] http://issues.apache.org/jira/browse/ADFFACES-6 -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Thoughts about unit testing and mock objects
I do believe as well that jMock doesn't provide enough context for writing proper tests of JSF-behaviour. At leasts whatever tests I have written so far needed some more than just a method to call and the information on whether this method has been called. regards, Martin On 5/13/06, Adam Winer [EMAIL PROTECTED] wrote: On 5/12/06, John Fallows [EMAIL PROTECTED] wrote: On 5/12/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/12/06, John Fallows [EMAIL PROTECTED] wrote: On 5/10/06, Adam Winer [EMAIL PROTECTED] wrote: I thought more about this over the last few hours. I think my basic gripe with easymock and mockobject approaches to JSF API objects is that most of the JSF tests I write rarely are concerned specifically with testing how my code is interacting with the JSF API; it's how my code is itself behaving. The former is where mock object suites pay dividends, but when your main concern is in your own code, mock suites seem to get in the way for more than they help. Basically, the Shale test framework seems like a better fit (yeah, handcoded, but that work's done and released...). I don't understand your point. Shale test framework is founded on mock objects. In addition, code we write in things like ADF Faces is going to assume certain behavior on the part of the JSF runtime -- I like to use a mock object framework that behaves enough like the real thing so that I can test the parts of my code that depend on that behavior too, not just static unit tests on individual methods. Also, no one so far seems to have addressed the second question in the original post about how we should provide mock objects for our own code in our unit tests. It probably blurs the line between unit tests and system integration tests a bit, but I like to use the real objects, rather than mocks, whenever I can feasibly do so. Besides having to do less work (not building mocks for classes that can be used both at test time and runtime), this also reduces the risk that I will mistakenly program my own class to the possibly botched behavior of a badly written mock object, giving me a false sense of security when the tests pass ... Well I definitely agree about not wanting to hand-craft mock object implementations! Dynamic mock creation also seems to address that by not requiring an implementation and keeping the recipe for the behavior isolated to the unit test itself. This provides self-documenting tests which are especially useful for anyone trying to learn the semantics of the code. IMHO, unit testing is about verifying the semantics of each codepath in each method, aiming for 100% coverage. This is most easily verified if each codepath is unit tested in isolation, preventing cascading failures and minimizing initialization overhead (only create the objects used by the method codepath). The point about false positives is interesting. Let's assume that we don't have any reusable mock object implementations to possibly botch, instead we have a specification of expected behavior (to possibly botch!) inside each unit test method definition (using jMock). This is, I guess, Objection #1 for me. Why put the burden of defining proper JSF behavior into every test, instead of into a reusable mock implementation? It's not just a question of effort - it's one of correctness, since if that behavior can be independently defined in each test, it can be defined differently in each test. Then, the unit test reads as setup expectations, execute real object method, and verify actual behavior. And here's Objection #2: setup expectations is not a natural programming model. It requires defining criteria in a meta-programming language so that verify actual behavior becomes simply a call to a mock verify() method. Anything that isn't in this meta-language is either impossible or requires writing custom critierion objects which is tedious and verbose. And, my main Objection #3: most tests (not all, but most) that I write in JSF are not concerned with testing the behavior of the JSF objects. That is, I rarely care about testing how I invoked FacesContext or UIComponent or ViewHandler. So the assertions that the mock frameworks give me - method foo() was called once with certain parameters - don't actually help me very much! -- Adam The unit test verifies that the method behaves according to the expected semantics defined in the same method. With a minimal amount of expected behavior to specify in each unit test method, the general approach does not seem that error prone to me. Perhaps some of this setup just needs to be hoisted out of the unit test method in special cases, like Shale does for JSF specification objects. Lastly, I think that the best way to verify in-container behavior is to run the code in the actual container and update the isolated behavior specifications in
Re: REMINDER: *** Board Reports DUE! ***
Done. regards, Martin On 4/17/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Just in case no one (who's around this week) is monitoring the [EMAIL PROTECTED] list, The ADF Faces section of the April board report needs to be filled out. It's a wiki, so anyone should be able to help out. Just add what's going on and what's been accomplished. -- Forwarded message -- From: Noel J. Bergman [EMAIL PROTECTED] Date: Apr 16, 2006 6:47 PM Subject: RE: REMINDER: *** Board Reports DUE! *** To: general@incubator.apache.org See: http://wiki.apache.org/incubator/April2006 *STILL* waiting to hear from ADF Faces, Agila, AltRMI, Felix, Harmony, Kabuki, and WebWork 2. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
