Re: myfaces-builder-plugin notes
On Tue, Jun 10, 2008 at 3:05 PM, simon <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've found a couple of free hours for myfaces, and have some more stuff
> for discussion re the builder plugin:
>
> (1)
> trunk unit tests fail:
> Tests in error:
> testGetClientIdFacesContext(javax.faces.component.UIComponentBaseTest)
> testFindComponentString(javax.faces.component.UIComponentBaseTest)
>
> I'll try to find time to look into this.
>
Here I'm not have any problem. Maybe the problem is that
myfaces-builder-plugin and myfaces-builder-annotations snapshot is not
automatically build every day, so it is necessary do a manual deploy each
time something change (I forget to do this after the last commit).
>
> (2)
> Now that the "template" property has been added to JSFComponent, can the
> following be deleted?
> parent
> superClass
>
Yes, I did a revision and deleted the usage of this attributes (front end).
But this properties right now are used inside myfaces-builder-plugin, since
the concept is valid from the backend. The code that do the magic of
template is this:
Boolean template = getBoolean(clazz,"template",props, null);
// If the componentClass is not the same as the class with
// @JSFComponent annotation, the component class is generated
if (!clazz.getFullyQualifiedName().equals(componentClass)){
if (!(template != null && template.booleanValue()))
{
//If template is false or null, the superClass of the
generated
//class is the same class, otherwise is the same as the
parent
//class.
superClassName =
getString(clazz,"superClass",props,clazz.getFullyQualifiedName());
}
}
> (3)
> I'd like to clean up JSFJspProperty, as it doesn't feel quite right to
> me.
>
> == rename it?
>
> Firstly, how about renaming it to JSFAttribute, and documenting it as
> something like:
>
>
> Defines a logical property of a component that is accessed via the
> component's Attributes map, rather than javaBean getter/setter methods.
>
>
Maybe, but we need to check the usage of JSFJspProperty and JSFAttribute and
check if this is
compatible or not.
>
> This gets away from this jsp-specific emphasis; this data is relevant
> for all sorts of technologies other than jsp.
>
> == tagExcluded
>
> I'm also trying to figure out exactly what "tagExcluded=true" means on
> JSFJspProperty, and whether we can get rid of it.
>
> We managed to get rid of it for the "rendered" and "id" properties that
> some components (esp. UIViewRoot) inherit from their parent class due to
> broken OO design in the JSF spec, by simply implementing the appropriate
> methods. But obviously that won't work for getting rid of bad
> JSFJspProperty (aka JSFAttribute) declarations that exist on the parent
> class but not on the child.
>
> So I guess we do need some kind of annotation to say "please break the
> OO rules and don't inherit the setting that was on the parent". But I
> think we should make the name as ugly as possible to deter people from
> using it, eg
> @JSFAttribute excludeInheritedAttributeHack=true
>
Really, id, binding and renderer are the only properties that sometimes uses
extensively
@JSFJspProperty tagExcluded=true, because override it could cause problems
or be imposible (binding)
>
> I see that Tomahawk uses the tagExcluded feature a lot at the moment.
> This really does feel wrong. I'll try to look into this, but as I
> mentioned before, if the problem is that some Tomahawk components have
> broken inheritance models then I would rather refactor those components
> than hack the builder plugin. Of course we can postpone that refactoring
> until after the next tomahawk release is out; I'm just saying that I
> don't see widespread use of this excludeInheritedAttributeHack as the
> right solution.
>
Sure, we can take a look at this on the next release.
>
> === tagExcluded in macro files
>
> I see tagExcluded is used in componentClass11.vm:
>
> #if($utils.isPrimitiveClass($type) && !$property.tagExcluded)
> #set ($arrayIndex = $arrayIndex + 1)
>values[$arrayIndex] = ${field}Set;
> #end
>
> Is this ${field}Set thing a Trinidad-specific feature?
>
> Incidentally, I think there *might* be a bug here: the tagExcluded test
> is done here, but not at the point a dozen lines earlier when the size
> of the values array is being computed. But I'm not entirely clear what
> is happening here, so might be wrong.
>
The code for this template right now is this:
#if($utils.isPrimitiveClass($type) && !$property.isTagExcluded() )
#set ($arrayIndex = $arrayIndex + 1)
${field}Set = ((Boolean) values[$arrayIndex]).booleanValue();
#end
It is used as an additional variable for primitive values. Example:
public void restoreState(FacesContext facesContext, Object state)
{
Object[] values = (Object[])state;
super.restoreState(facesContext,values[0]);
_actionFor = (java.lang
[jira] Created: (TRINIDAD-1116) Issue with the Key used in FileSystemStyleCache
Issue with the Key used in FileSystemStyleCache --- Key: TRINIDAD-1116 URL: https://issues.apache.org/jira/browse/TRINIDAD-1116 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.8-core Reporter: Stevan Malesevic IN the Trinidad 1.2.8 Key object from org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache.Key got changed to have version as a string rather then int. This broke the equals method where the comparison is doen with "!=" and it should now be string equals like : !_version.equals(key._version) This issue has a big side affect that entries in the cache are created multiple time -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
myfaces-builder-plugin notes
Hi,
I've found a couple of free hours for myfaces, and have some more stuff
for discussion re the builder plugin:
(1)
trunk unit tests fail:
Tests in error:
testGetClientIdFacesContext(javax.faces.component.UIComponentBaseTest)
testFindComponentString(javax.faces.component.UIComponentBaseTest)
I'll try to find time to look into this.
(2)
Now that the "template" property has been added to JSFComponent, can the
following be deleted?
parent
superClass
(3)
I'd like to clean up JSFJspProperty, as it doesn't feel quite right to
me.
== rename it?
Firstly, how about renaming it to JSFAttribute, and documenting it as
something like:
Defines a logical property of a component that is accessed via the
component's Attributes map, rather than javaBean getter/setter methods.
This gets away from this jsp-specific emphasis; this data is relevant
for all sorts of technologies other than jsp.
== tagExcluded
I'm also trying to figure out exactly what "tagExcluded=true" means on
JSFJspProperty, and whether we can get rid of it.
We managed to get rid of it for the "rendered" and "id" properties that
some components (esp. UIViewRoot) inherit from their parent class due to
broken OO design in the JSF spec, by simply implementing the appropriate
methods. But obviously that won't work for getting rid of bad
JSFJspProperty (aka JSFAttribute) declarations that exist on the parent
class but not on the child.
So I guess we do need some kind of annotation to say "please break the
OO rules and don't inherit the setting that was on the parent". But I
think we should make the name as ugly as possible to deter people from
using it, eg
@JSFAttribute excludeInheritedAttributeHack=true
I see that Tomahawk uses the tagExcluded feature a lot at the moment.
This really does feel wrong. I'll try to look into this, but as I
mentioned before, if the problem is that some Tomahawk components have
broken inheritance models then I would rather refactor those components
than hack the builder plugin. Of course we can postpone that refactoring
until after the next tomahawk release is out; I'm just saying that I
don't see widespread use of this excludeInheritedAttributeHack as the
right solution.
=== tagExcluded in macro files
I see tagExcluded is used in componentClass11.vm:
#if($utils.isPrimitiveClass($type) && !$property.tagExcluded)
#set ($arrayIndex = $arrayIndex + 1)
values[$arrayIndex] = ${field}Set;
#end
Is this ${field}Set thing a Trinidad-specific feature?
Incidentally, I think there *might* be a bug here: the tagExcluded test
is done here, but not at the point a dozen lines earlier when the size
of the values array is being computed. But I'm not entirely clear what
is happening here, so might be wrong.
Comments?
Cheers,
Simon
Re: svn commit messages
Thank you guys for telling about this. Iam always missing this. On Tue, Jun 10, 2008 at 9:45 PM, simon <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-06-10 at 18:32 +0200, Volker Weber wrote: > > Hi Team, > > > > to those who commits just with the jira id as message: > >Please add at least the jira title to the message. > > I have no id was e.g MYFACES-1234 is, and no time to do always a jira > lookup. > > +1 > > Looking at commit emails, or svn history, it's really inconvenient to > have to look up JIRA to get a clue about what the change did. And JIRA > data is more likely to disappear in future than svn commit messages. > > > > > An to those who don't adding a jira id: > > if you add the id we can track the related checkins in jira, so please > do. > > +1 to this too. > > > -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: svn commit messages
On Tue, 2008-06-10 at 18:32 +0200, Volker Weber wrote: > Hi Team, > > to those who commits just with the jira id as message: >Please add at least the jira title to the message. > I have no id was e.g MYFACES-1234 is, and no time to do always a jira lookup. +1 Looking at commit emails, or svn history, it's really inconvenient to have to look up JIRA to get a clue about what the change did. And JIRA data is more likely to disappear in future than svn commit messages. > > An to those who don't adding a jira id: > if you add the id we can track the related checkins in jira, so please do. +1 to this too.
Re: [TRINIDAD] Proposed changes to Trinidad POM files
> The only thing that will change as a result of these updates is in our > Trinidad 1.2.x distribution. Currently the Trinidad Demo for 1.2.x project > is distributed with MyFaces in the web-inf lib, and not JSTL.. This neither > fits the requirements for a full J2EE container (which should include > neither), nor does it fit the requirements for Tomcat (which should include > both). The current proposal would build the demo without either of these > libraries deployed in the WEB-INF/lib directory, but through the use of > profiles would make it easy to include one, the other, or both. If anyone > cares about any of this, chime in. If not, I expect this POM's to be active > shortly in trunk_1.2.x. +1 > > I am also going to make the same enhancements to the Trinidad 1.1 > distribution, but in that distro, JSF 1.1 will always be included and a > couple of other options which are 1.2 specific will not be available. > > I'll upload the 1.2.x patch shortly for review and the 1.0.x patch should be > up later today.. https://issues.apache.org/jira/browse/TRINIDAD-1089. thanks for addressing this. -M > > Thanks. > Scott > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
svn commit messages
Hi Team, to those who commits just with the jira id as message: Please add at least the jira title to the message. I have no id was e.g MYFACES-1234 is, and no time to do always a jira lookup. An to those who don't adding a jira id: if you add the id we can track the related checkins in jira, so please do. Thanks, Volker -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de
[TRINIDAD] Proposed changes to Trinidad POM files
Hey everyone, in order to solve TRINIDAD-1089, I'm proposing some changes to the Trinidad POM files and I think they will make things much easier. While I was in there, I also cleaned them up quite a bit and eliminated much of the redundancy. The only thing that will change as a result of these updates is in our Trinidad 1.2.x distribution. Currently the Trinidad Demo for 1.2.x project is distributed with MyFaces in the web-inf lib, and not JSTL.. This neither fits the requirements for a full J2EE container (which should include neither), nor does it fit the requirements for Tomcat (which should include both). The current proposal would build the demo without either of these libraries deployed in the WEB-INF/lib directory, but through the use of profiles would make it easy to include one, the other, or both. If anyone cares about any of this, chime in. If not, I expect this POM's to be active shortly in trunk_1.2.x. I am also going to make the same enhancements to the Trinidad 1.1 distribution, but in that distro, JSF 1.1 will always be included and a couple of other options which are 1.2 specific will not be available. I'll upload the 1.2.x patch shortly for review and the 1.0.x patch should be up later today.. https://issues.apache.org/jira/browse/TRINIDAD-1089. Thanks. Scott
[jira] Commented: (TRINIDAD-1089) trinidad-demo.war does not run in non-J2EE container as distributed.
[ https://issues.apache.org/jira/browse/TRINIDAD-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603922#action_12603922 ] Scott O'Bryan commented on TRINIDAD-1089: - While I'm not so keen to provide top-level pre-built support for non-j2ee container, it seems that the current demo will work (as-is) in neither a standard J2EE environment OR in tomcat. The reason for this is that MyFaces is packaged, by default, with the demos. So if we have a standard J2EE container, MyFaces will interfere with the built-in implementation. Jetty has JSTL and NOT faces, and Tomcat has neither. Furthermore, the Trinidad POMS are hard to manage and it has been a while since they've been updated. Therefore, here is my proposal to solve this issue: * By default the demo's will include neither JSF nor JSTL libraries. These will no longer be present in the distribution. * Add two profiles which may be used from maven to support adding these to a custom build of the demo projects: includeJSF and includeJSTL * Continue to support the jettyConfig parameter which will include JSF and not JSTL by default * Continue to support the jsf=ri property to select which version of JSF gets packaged with the demo or used with Jetty My enhancements also include much better versioning support (thorough properties) for Trinidad's dependent libraries and a "release" profile which is automatically activated when a mvn release:perform is done instead of having to do a mvn release:perform -Prelease like we have to do today. It also includes an includeBridge profile which will include the bridge jars for testing the demo in a portlet environment. I've also cleaned up the -DprepareRelease profile activation to work much cleaner with the assembly projects. If these changes look good, I'll check this in along with some documentation which outlines these build options so it should be possible to generate a war file for use in just about any container. > trinidad-demo.war does not run in non-J2EE container as distributed. > > > Key: TRINIDAD-1089 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1089 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.0.8-core, 1.2.8-core >Reporter: Paul Spencer >Assignee: Scott O'Bryan > > The trinidad-demo.war does not run in a non-J2EE container, like Tomcat, as > distributed in examples.zip/tar.gz. This is due to a missing JSTL jar which > is provided by a J2EE container. This improvement is simplify the process of > installing the demo in a non-J2EE container. Changes should include > documentation included in the distribution and available on demo project's > web site. Additional change may be required in the POM. > Their is a related thread titled "Trinidad] Should a non-J2EE demo war be > added to the distribution" in the myfaces-dev mailing list. [1] > *** > * The procedure I used to run trinidad-demo.war in Tomcat 6.0.16 > *** > 1) Download the examples distribution > 2) Copy the trinidad-demo.war from the distribution to Tomcat's webapps > directory > 3) After Tomcat exploded the war, I copied jstl-1.2.jar into the WEB-INF/lib > directory of the exploded war. > 4) Restart tomcat. > [1] http://markmail.org/message/7ah2zedr57ppzfx6 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1278) promoting the subform component to Tomahawk
promoting the subform component to Tomahawk --- Key: TOMAHAWK-1278 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1278 Project: MyFaces Tomahawk Issue Type: Task Affects Versions: 1.1.7-SNAPSHOT Reporter: Hazem Saleh Assignee: Hazem Saleh Fix For: 1.1.7-SNAPSHOT -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1115) Icon Selectors stopped working: .AFShuttleMoveIcon:alias et. al.
Icon Selectors stopped working: .AFShuttleMoveIcon:alias et. al.
Key: TRINIDAD-1115
URL: https://issues.apache.org/jira/browse/TRINIDAD-1115
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.7-core
Reporter: Stephen Friedrich
This skinning selector used to work for tr:selectManyShuttle
.AFShuttleMoveIcon:alias {
content: url(/images/icons_right.gif);
width: 15px;
height: 15px;
}
In Trinidad 1.2.7 I don't get any icon at all (because I have set the texts
empty I event get nothing at all).
A workaround is to use
af|selectManyShuttle::move-icon {
content: url(/images/icons_right.gif);
width: 15px;
height: 15px;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] promoting the subform component to Tomahawk
+1 On Mon, Jun 9, 2008 at 5:54 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote: > Hi Team, > > I wish to promote this subForm component to the next Tomahawk release. > > [+1] for agreeing with promoting the component to the next Tomahawk release. > [-1] for disagreeing with promoting the component to the next Tomahawk > release. > > > Thanks all very much! > > -- > Hazem Ahmed Saleh Ahmed > http://www.jroller.com/page/HazemBlog -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Result (was Re: [VOTE] name for 'seven')
thank you for voting! result: myfaces-extensions-validator details: all binding votes (pmc) are +1 votes for myfaces-extensions-validator in chronological order: - Andrew Robinson - Grant Smith - Werner Punz - Matthias Wessendorf there are no -1 votes for myfaces-extensions-validator regards, gerhard 2008/6/6 Matthias Wessendorf <[EMAIL PROTECTED]>: > +1 for myfaces-extensions-validator > -1 for myfaces-extensions-seven > -1 for myfaces-extensions-jack > > On Fri, Jun 6, 2008 at 7:35 PM, Grant Smith <[EMAIL PROTECTED]> wrote: > > +1 for myfaces-extensions-validator > > > > -1 for myfaces-extensions-seven > > > > -1 for myfaces-extensions-jack > > > > On Fri, Jun 6, 2008 at 8:31 AM, Andrew Robinson > > <[EMAIL PROTECTED]> wrote: > >> > >> +1 for myfaces-extensions-validator > >> > >> +0 for myfaces-extensions-seven > >> > >> -0.5 for myfaces-extensions-jack > >> > >> On Fri, Jun 6, 2008 at 6:50 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote: > >> > +1 for myfaces-extensions-seven, IMO it rocks. > >> > > >> > On Fri, Jun 6, 2008 at 3:43 PM, Gerhard Petracek > >> > <[EMAIL PROTECTED]> wrote: > >> >> > >> >> +1 for myfaces-extensions-seven > >> >> > >> >> 2008/6/6 Gerhard Petracek <[EMAIL PROTECTED]>: > >> >>> > >> >>> hello, > >> >>> > >> >>> there are no new name suggestions concerning 'seven' [1]. > >> >>> so i suggest to start the vote. > >> >>> > >> >>> the new meaning of the acronym: > >> >>> > >> >>> simple enhanced validation with extensible nature > >> >>> > >> >>> seven will be part of myfaces-extensions [2] > >> >>> > >> >>> i suggest the following choices: > >> >>> 1) myfaces-extensions-seven > >> >>> 2) myfaces-extensions-jack > >> >>> 3) myfaces-extensions-validator > >> >>> > >> >>> > >> >>> [ ] +1 for the preferred name > >> >>> [ ] +0 > >> >>> [ ] -1 to place a veto for a name > >> >>> > >> >>> > >> >>> regards, > >> >>> gerhard > >> >>> > >> >>> [1] > http://www.mail-archive.com/dev@myfaces.apache.org/msg31960.html > >> >>> [2] > http://www.mail-archive.com/dev@myfaces.apache.org/msg32712.html > >> >>> > >> >>> -- > >> >>> > >> >>> 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 > >> > > >> > > >> > -- > >> > Hazem Ahmed Saleh Ahmed > >> > http://www.jroller.com/page/HazemBlog > > > > > > > > -- > > Grant Smith > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] promoting the subform component to Tomahawk
+1 2008/6/10 Hazem Saleh <[EMAIL PROTECTED]>: > Great, we have now 2 positive votes. > > I will start promoting it after waiting another 24 hours. > > On Mon, Jun 9, 2008 at 8:02 PM, Grant Smith <[EMAIL PROTECTED]> wrote: >> >> +1 >> >> On Mon, Jun 9, 2008 at 8:56 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote: >>> >>> +1. >>> >>> On Mon, Jun 9, 2008 at 6:54 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote: Hi Team, I wish to promote this subForm component to the next Tomahawk release. [+1] for agreeing with promoting the component to the next Tomahawk release. [-1] for disagreeing with promoting the component to the next Tomahawk release. Thanks all very much! -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog >>> >>> >>> -- >>> Hazem Ahmed Saleh Ahmed >>> http://www.jroller.com/page/HazemBlog >> >> >> -- >> Grant Smith > > > > -- > Hazem Ahmed Saleh Ahmed > http://www.jroller.com/page/HazemBlog
Re: [VOTE] promoting the selectManyPicklist component to Tomahawk
+1 2008/6/9 Grant Smith <[EMAIL PROTECTED]>: > +0, Sorry I have not been able to find time to test this one yet. > > On Mon, Jun 9, 2008 at 8:41 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote: >> >> +1. >> >> On Mon, Jun 9, 2008 at 6:41 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote: >>> >>> Hi Team, >>> >>> After updating the selectManyPicklist documentation. >>> >>> I wish to promote this selectManyPicklist (created by Bruno) to the next >>> Tomahawk release. >>> >>> [+1] for agreeing with promoting the component to the next Tomahawk >>> release. >>> [-1] for disagreeing with promoting the component to the next Tomahawk >>> release. >>> >>> >>> If there are any known issues, I can spend sometime at. >>> >>> Thanks all very much! >>> >>> >>> -- >>> Hazem Ahmed Saleh Ahmed >>> http://www.jroller.com/page/HazemBlog >> >> >> -- >> Hazem Ahmed Saleh Ahmed >> http://www.jroller.com/page/HazemBlog > > > -- > Grant Smith >
Re: [VOTE] promoting the subform component to Tomahawk
Great, we have now 2 positive votes. I will start promoting it after waiting another 24 hours. On Mon, Jun 9, 2008 at 8:02 PM, Grant Smith <[EMAIL PROTECTED]> wrote: > +1 > > > On Mon, Jun 9, 2008 at 8:56 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote: > >> +1. >> >> >> On Mon, Jun 9, 2008 at 6:54 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote: >> >>> Hi Team, >>> >>> I wish to promote this subForm component to the next Tomahawk release. >>> >>> [+1] for agreeing with promoting the component to the next Tomahawk >>> release. >>> [-1] for disagreeing with promoting the component to the next Tomahawk >>> release. >>> >>> >>> Thanks all very much! >>> >>> -- >>> Hazem Ahmed Saleh Ahmed >>> http://www.jroller.com/page/HazemBlog >> >> >> >> >> -- >> Hazem Ahmed Saleh Ahmed >> http://www.jroller.com/page/HazemBlog >> > > > > -- > Grant Smith > -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
[jira] Created: (TRINIDAD-1114) Modal Date Picker Dialog and IE 7 hangs with open popups in tab (register card)
Modal Date Picker Dialog and IE 7 hangs with open popups in tab (register card) Key: TRINIDAD-1114 URL: https://issues.apache.org/jira/browse/TRINIDAD-1114 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.6-core Reporter: Jan Görß when click on datepicker image - open calendar popup in new tab and ie 7 hangs -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
