RE: Tomahawk compatibility table
I am disappointed by the attitude expressed here. Testing whether two related projects are compatible should be a basic part of the release process. It is simple QA. That so many releases have gone through without such an essential check raises questions about the competence of those involved in this project. Since Tomahawk 1.1.3 and Core 1.1.4, there have been several releases of each. Just finding a compatible pair of versions is a daunting task for anyone given the number of possible combinations, especially when trying to adjust for incompatible changes among the versions of each project. I have not yet found a single match of newer versions of Tomahawk and Core that are compatible. Having used MyFaces for three years now, I can safely say that leaving this important task to even less experienced users is ridiculous. The developers need to take responsibility for their work. Richard J. Barbalace Boston, MA, USA -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Friday, February 01, 2008 8:07 AM To: dev@myfaces.apache.org Subject: Tomahawk compatibility table Hi, I'm getting really annoyed with all the why isn't the tomahawk compatibility table up to date questions. Unless someone vetos it, I'll just rip that page out of the site tonight, and put the existing info up on the wiki instead. Then users have only themselves to blame if it is not up-to-date. Regards, Simon The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
Compatibility Matrix severely out of date
Hello. The Compatibility Matrix is so severely out of date as to be useless. Could someone familiar with the releases update this on the wiki: http://wiki.apache.org/myfaces/CompatibilityMatrix I have been trying to upgrade Tomahawk (from 1.1.3) and MyFaces core (from 1.1.4, the last compatible match) on my projects, but figuring out which versions to use has not been easy to say the least. Richard J. Barbalace Software Developer Orthopaedics Biomechanics and Biomaterials Laboratory Massachusetts General Hospital 55 Fruit Street, Jackson 1121 Boston, MA 02114 Tel: 617-726-3607 Fax: 617-726-3883 The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
RE: myFaces vs MyFaces ... what do you think ?
I dislike the use of the lowercase m in the particular font used in the logo, because it makes the ambiguous F/f look lowercase as well. With the lowercase m, I see the logo as myfaces not myFaces. With the capital M, I see it as MyFaces. I would definitely rather read MyFaces than myfaces, but feel less strongly about myFaces. I think consistency across the project names is important though, so I slightly favor the capital M. Richard J. Barbalace Boston, MA, USA -Original Message- From: Adonis Raduca [mailto:[EMAIL PROTECTED] Sent: Saturday, December 08, 2007 10:33 AM To: dev@myfaces.apache.org Subject: myFaces vs MyFaces ... what do you think ? Hello I look on all comments and I seen the majority agree with the MyFaces capital M version. I know that many of us are familiar with MyFaces version and I either. I propose the myFaces, small m from the differentiation reasons. Now a days we are invaded with names like MySpace, MyPortal, MyDocuments, MySomething, MyXxxx. All of them are written with capital M, small y, after a word that starts with a capital letter. So I tried to avoid this common pattern and provide myFaces with a distinctive look, which stands out from the crowd ... after all a brand means personality we must be open minded ... :) What do you think ? Have a nice weekend ! Adonis Never miss a thing. Make Yahoo your homepage. http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
RE: MyFaces logo
Not that my opinion should count for much, but I like 7, 8, and 10. I think the first shape (first five images) makes the one face express a somewhat horrified expression; the second shape (last five images) with the smile is much friendlier. I like the multiple colors as well, aside from the too Christmasy green and red pair. Richard J. Barbalace -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Friday, November 30, 2007 9:26 AM To: MyFaces Development; Adonis Raduca Subject: Fwd: MyFaces logo Hey everyone, What do you think of a new MyFaces logo, like the one proposed by Adonis in the following pdf? regards, martin -- Forwarded message -- From: Adonis Raduca [EMAIL PROTECTED] Date: Nov 30, 2007 1:19 PM Subject: MyFaces logo To: Catalin Kormos [EMAIL PROTECTED], Catalin Kormos [EMAIL PROTECTED], [EMAIL PROTECTED] Hello We have a nice logo for MyFaces project. The logo consists of two stylized faces in the puzzle-like shape that represents interconnectivity and modular architecture. We achieved an interesting exotic touch using a tribal-like painting style for those faces. I tried to avoid the omnipresent blue color to differentiate from the crowd and especially from ICEfaces product, so I use a warm color combination in the Ubuntu african stile. In the attached file we have 2 shape and 5 color variations of the logo. Personally I recommend the 5th and 10th samples because its good contrast and color balancing. Have a nice weekend ! Adonis -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
SVN tags for latest releases?
Hello. I noticed in the SVN repository that there are no tags for the 1.2.0 release of the Core or the 1.1.6 release of Tomahawk. The branches are available, but no tags. Since these are released, should there be tags? Also, is there anyone willing and able to update the compatibility matrix on the wiki? It would be helpful to those upgrading from earlier versions to have this up-to-date: http://wiki.apache.org/myfaces/CompatibilityMatrix Thanks. Richard J. Barbalace Software Developer Orthopaedics Biomechanics and Biomaterials Laboratory Massachusetts General Hospital 55 Fruit Street, Jackson 1121 Boston, MA 02114 Tel: 617-726-3607 Fax: 617-726-3883 The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
RE: Re: Trinidad, Tomahawk, Tobago, and RCF [Was: [Proposal] RCF, a rich component library for JSF]
As someone who mostly just lurks on the dev list, I did want to comment on Werner's post. I would be very interested in component programming, and I have a fair number of ideas for what I think would make useful and interesting components. (Wouldn't it be nice to have a Google Maps component, for instance?) But trying to figure out even how to get started is frustrating. There are all these different projects, with seemingly different purposes, with scattered or poor documentation, and with no single place for getting a top-down overview. Having a nice, clear taxonomy of all the projects and their relationships would be a helpful start, but it would be so much better if there were better integration. I personally would be unlikely to start developing components until that is achieved. Richard J. Barbalace -Original Message- From: Werner Punz [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 11:48 AM To: dev@myfaces.apache.org Subject: Re: Trinidad, Tomahawk, Tobago, and RCF [Was: [Proposal] RCF, a rich component library for JSF] . Getting people into component programming is hard, the api is unnecessarily complicated and overloaded with glue code, a common base, could ease tool development as well (we need well documented codegens and uis for helping people to kickstart it). one third is inherent incompatibility problems and one third is questions And the first question you geht, why so many components in the sets double... And then we have Tobago, an excellent framework which feels like being one big block designed for coherency and it has also problems working together with the rest. I think it is long overdue to get a good corebase here and more coherency, since there has to be done some overhaul for jsf 1.2, why not in a proper and decent manner. The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
RE: MyFaces Fusion Naming
I would pronounce Kleber as klee-ber with a long E sound like cleaver (a large knife or an instrument for cutting things apart, which might be ironic given the word's meaning in German). The word Kleber has no obvious meaning in English. Even after reading the description on the Wiki page, I still have no idea what this stuff is supposed to do or how it is to be used. If it has primarily to do with something called conversations (whatever that means), maybe use a name like conversation or a synonym in some language would be better? Richard J. Barbalace Cambridge, MA, USA -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 9:21 AM To: MyFaces Development Subject: Re: MyFaces Fusion Naming It probably sounds like Clever. It looks like Keebler (a cookie/cracker manufacturer). On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hey, I wonder how Kleber sounds for English native speakers? I bet it sounds horrible . I hope so :-) Ciao, Mario The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
RE: [VOTE] MyFaces Core 1.1.5
Hi. Looking at the release notes, I see: Release Notes - MyFaces Core - Version 1.1.5 ** Bug * [long listing of bugs] This phrasing is ambiguous. Are these bugs present in the Release, or bugs fixed in the Release? This might be obvious to developers, but release notes should be more friendly to end users who might otherwise be frightened away. Richard J. Barbalace -Original Message- From: Manfred Geiler [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 14, 2007 7:29 AM To: MyFaces Development Subject: [VOTE] MyFaces Core 1.1.5 Hi all, This is the official vote for MyFaces Core 1.1.5. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.maven v1.0.5 [1] 2. Maven artifact group org.apache.myfaces.shared v2.0.5 [1] 3. Maven artifact group org.apache.myfaces.core v1.1.5 [1] 4. MyFaces Core Assembly [2] 5. Proposed Release Announcement [3] [1] http://people.apache.org/builds/myfaces/m2-staging-repository/ [2] http://people.apache.org/builds/myfaces/core-1.1.5/ [3] http://wiki.apache.org/myfaces/CoreRelease115#releasenotes --Manfred The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
RE: [jira] Created: (TOMAHAWK-615) Exporting DataTable data to excel
Hi. I am not sure of the best implementation for this feature, but I want to note that I think the feature itself would be valuable. My organization had to write a custom export servlet to do just this for some of our data tables, so providing this functionality within MyFaces may have been a nice time-saver as well as possibly easing maintenance. I am not quite sure what is meant by excel format. We are exporting as text/csv from our application. It may be worth allowing a few common formats, including tab-separated values, for greater generality. + Richard -Original Message- From: Cagatay Civici (JIRA) [mailto:[EMAIL PROTECTED] Sent: Thursday, August 24, 2006 2:48 AM To: dev@myfaces.apache.org Subject: [jira] Created: (TOMAHAWK-615) Exporting DataTable data to excel Exporting DataTable data to excel - Key: TOMAHAWK-615 URL: http://issues.apache.org/jira/browse/TOMAHAWK-615 Project: MyFaces Tomahawk Issue Type: New Feature Reporter: Cagatay Civici Assigned To: Cagatay Civici Priority: Minor A new component to allow exporting the data of a datatable to the excel format using AJAX background. The usage will be like; s:excelExporter for=tableIdHere / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
FW: MyFacesHack.js bug...
Hello.
I sent this to the list last week, but think it may have been lost as I was not
currently subscribed.
+ Richard
-Original Message-
From: Barbalace, Richard
Sent: Friday, June 30, 2006 1:21 PM
To: 'dev@myfaces.apache.org'
Cc: Barbalace, Richard
Subject: MyFacesHack.js bug...
Hello.
Last November, I submitted some JavaScript changes for the JSCookMenu component,
which have been incorporated into MyFacesHack.js in the most recent release
(1.1.3). These lines (23 through 25 of that file), however, were changed
slightly from my original version:
// Link is a script method
link = link.replace(/^\w*:A\]\w*:/, ); // Remove JSF ID
eval(link);
I think the intent here was to remove the MyFaces ID as well as the
javascript: tag before evaluating the code. This fails, however, for
mailto:; links, which also use that replacement. This may also fail in the
rare case that the scripting language specified in the link is something other
than JavaScript. They may be other cases that fail as well.
Instead of eval'ing the code as above, I recommend reverting to something closer
to my original suggestion. Here is the corrected code, showing the full
section:
// changes by Richard J. Barbalace
if (link.match(/^\w*:A\]\w*:\/\//) != null ) {
// Link is a URL
link = link.replace(/^\w*:A\]/, ); // Remove JSF ID
window.open (link, target);
} else if (link.match(/^\w*:A\]\w*:/) != null ) {
// Link is a script method
link = link.replace(/^\w*:A\]/, ); // Remove JSF ID
window.open (link, '_self');
} else {
// Link is a JSF action
var dummyForm = document.forms[target];
dummyForm.elements['jscook_action'].value = link;
dummyForm.submit();
Using the window.open call allows the browser to interpret javascript: or
mailto:; links properly, rather than having to provide special cases for every
possibility in the IF statement itself. I have tested this successfully on
Firefox and IE on Windows, but more testing would be helpful.
Richard J. Barbalace
Software Developer
Harris Orthopaedics Biomechanics and Biomaterials Laboratory
Massachusetts General Hospital
55 Fruit Street, Jackson 1121
Boston, MA 02114
Tel: 617-726-3607
Fax: 617-726-3883
MyFacesHack.js bug...
Hello.
Last November, I submitted some JavaScript changes for the JSCookMenu component,
which have been incorporated into MyFacesHack.js in the most recent release
(1.1.3). These lines (23 through 25 of that file), however, were changed
slightly from my original version:
// Link is a script method
link = link.replace(/^\w*:A\]\w*:/, ); // Remove JSF ID
eval(link);
I think the intent here was to remove the MyFaces ID as well as the
javascript: tag before evaluating the code. This fails, however, for
mailto:; links, which also use that replacement. This may also fail in the
rare case that the scripting language specified in the link is something other
than JavaScript. They may be other cases that fail as well.
Instead of eval'ing the code as above, I recommend reverting to something closer
to my original suggestion. Here is the corrected code, showing the full
section:
// changes by Richard J. Barbalace
if (link.match(/^\w*:A\]\w*:\/\//) != null ) {
// Link is a URL
link = link.replace(/^\w*:A\]/, ); // Remove JSF ID
window.open (link, target);
} else if (link.match(/^\w*:A\]\w*:/) != null ) {
// Link is a script method
link = link.replace(/^\w*:A\]/, ); // Remove JSF ID
window.open (link, '_self');
} else {
// Link is a JSF action
var dummyForm = document.forms[target];
dummyForm.elements['jscook_action'].value = link;
dummyForm.submit();
Using the window.open call allows the browser to interpret javascript: or
mailto:; links properly, rather than having to provide special cases for every
possibility in the IF statement itself. I have tested this successfully on
Firefox and IE on Windows, but more testing would be helpful.
Richard J. Barbalace
Software Developer
Harris Orthopaedics Biomechanics and Biomaterials Laboratory
Massachusetts General Hospital
55 Fruit Street, Jackson 1121
Boston, MA 02114
Tel: 617-726-3607
Fax: 617-726-3883
RE: JavaScript in jsCookMenu component?
Hi, Thomas.
Below is my final version of the modified cmItemMouseUp() method. It should
work with any protocol and scripting language.
The method checks the link for the portion right after the JSF tag. If this is
a word followed by ://, it assumes the link is a URL, which is opened in a new
window. Otherwise, if this is a word followed by :, it assumes the link is a
scripted method. Otherwise, it assumes the link is a JSF action. I think this
is a reasonable and simple approach, but I recommend more testing by others.
Let me know if you have any questions.
I look forward to seeing this or something similar in the next release of
MyFaces.
Thanks.
+ Richard
function cmItemMouseUp (obj, index)
{
var item = _cmItemList[index];
var link = null, target = '_self';
if (item.length 2)
link = item[2];
if (item.length 3 item[3])
target = item[3];
if (link != null)
{
// changes by Richard J. Barbalace
if (link.match(/^\w*:\w*:\/\//) != null ) {
// Link is a URL
link = link.replace(/^\w*:/, ); // Remove JSF ID
window.open (link, target);
} else if (link.match(/^\w*:\w*:/) != null ) {
// Link is a script method
link = link.replace(/^\w*:/, ); // Remove JSF ID
window.open (link, '_self');
} else {
// Link is a JSF action
var dummyForm = document.forms['linkDummyForm'];
dummyForm.elements['jscook_action'].value = link;
dummyForm.submit();
}
}
var prefix = obj.cmPrefix;
var thisMenu = cmGetThisMenu (obj, prefix);
var hasChild = (item.length 5);
if (!hasChild)
{
if (cmIsDefaultItem (item))
{
if (obj.cmIsMain)
obj.className = prefix + 'MainItem';
else
obj.className = prefix + 'MenuItem';
}
cmHideMenu (thisMenu, null, prefix);
}
else
{
if (cmIsDefaultItem (item))
{
if (obj.cmIsMain)
obj.className = prefix + 'MainItemHover';
else
obj.className = prefix + 'MenuItemHover';
}
}
}
-Original Message-
From: Thomas Spiegl [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 03, 2005 5:57 PM
To: MyFaces Development
Cc: Simon Kitching; [EMAIL PROTECTED]; Barbalace, Richard
Subject: Re: JavaScript in jsCookMenu component?
Can you send me a final verion for cmItemMouseUp? I will patch the
current version.
Thomas
On 11/2/05, Barbalace, Richard [EMAIL PROTECTED] wrote:
Simon Kitching [mailto:[EMAIL PROTECTED] writes:
I'd rather see detection of *any* protocol on the front
of the URL
rather than checking just for http:. The protocols
https:, mail:
etc are also useful.
== proposal: ==
The URL *always* has menu_id: on the start, so
presumably the jscript
could just strip this ID off then look for a : before
any occurrence
of / or ?. If that is present, then the URL is
absolute. And if
that is not present but the URL contains a / then it
isn't an action
so treat that as a local URL.
I would have done something similar to that originally, but
I was not sure how
consistent the menu_id: string was or if that string
might change in the
future. The string is actually id0_menu: in the version
I am using, at least
for the first jsCookMenu element on the page.
That proposal sounds almost fine to me. The code needs to
check for only : in
the case of scripting languages. For example, one of my actions is
id0_menu:javascript:getHelp();, which contains no /
character. I am not
sure what the ideal regular expression would be, but it
would definitely check
for :, /, and ?. Perhaps that would be enough; can
any of those
characters be used in a JSF action name?
Thanks.
+ Richard
RE: JavaScript in jsCookMenu component?
Simon Kitching [mailto:[EMAIL PROTECTED] writes: I'd rather see detection of *any* protocol on the front of the URL rather than checking just for http:. The protocols https:, mail: etc are also useful. == proposal: == The URL *always* has menu_id: on the start, so presumably the jscript could just strip this ID off then look for a : before any occurrence of / or ?. If that is present, then the URL is absolute. And if that is not present but the URL contains a / then it isn't an action so treat that as a local URL. I would have done something similar to that originally, but I was not sure how consistent the menu_id: string was or if that string might change in the future. The string is actually id0_menu: in the version I am using, at least for the first jsCookMenu element on the page. That proposal sounds almost fine to me. The code needs to check for only : in the case of scripting languages. For example, one of my actions is id0_menu:javascript:getHelp();, which contains no / character. I am not sure what the ideal regular expression would be, but it would definitely check for :, /, and ?. Perhaps that would be enough; can any of those characters be used in a JSF action name? Thanks. + Richard
