date:20060413

Werner,Look at the component classes. Everything between the BEGIN and END GENERATED CODE markers was generated by a Velocity template from the according component xml files.In a few minutes I will checkin the reborn codegenerator - stay tuned.
ManfredOn 4/13/06, Werner Punz [EMAIL PROTECTED] wrote:
Manfred Geiler schrieb: Ok, I just spent a few minutes and found the old codegenerator on the attic. Will try to integrate it into current maven structure. Please stay tuned! Thanks,
 ManfredManfred, just a question, what was the scope of the old codegenerator,does it generated boilerplate code for the components?

Re: Puzzled about generated code

2006-04-13 Thread Werner Punz

Manfred Geiler schrieb:
 Werner,
 Look at the component classes. Everything between the BEGIN and END
 GENERATED CODE markers was generated by a Velocity template from the
 according component xml files.
 In a few minutes I will checkin the reborn codegenerator - stay tuned.
 
Ah superb, I was looking for such a thing for a long time.
I knew something was done back then for the wml stuff, but I never had
time to dig into it.
Lovely stuff, will save a lot of time.

Re: Provide Patch / Cancel Patch

2006-04-13 Thread Volker Weber

Hi Sean,

are you sure? It looks like just a anonymous user triggers this, see

http://issues.apache.org/jira/browse/TOBAGO-54?page=all



Regards,
  Volker


Sean Schofield wrote:
 Done.  Users must have the same permissions as for Create Issue (which
 is to say they must be logged in.)
 
 Sean
 
 On 3/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 
I'm wondering if it'd be possible to restrict Provide Patch to
logged-in users.
It's annoying when an anonymous user triggers this with a patch
because there's no way to identify them in order to educate them as to
why it was the wrong thing to do.

On 3/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

Is there any way to have the JIRA notification mail state when one of
these buttons was pushed?

Right now we only get the following (Anon said there was a patch; I
cancelled the process because there wasn't one).


Anonymous (JIRA)
[ http://issues.apache.org/jira/browse/TOMAHAWK-134?page=all ]
 updated TOMAHAWK-134:

Mike Kienenberger (JIRA)
[ http://issues.apache.org/jira/browse/TOMAHAWK-134?page=all ]
Mike Kienenberger updated TOMAHAWK-134:


 

-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.

Code generator is back! (was: Puzzled about generated code)

Hi all,After finding some spare time yesterday and rummaging in the myfaces attic, I was able to re-add the long missed code generation feature. Hooray.Gert Vanthienen was kind enough to offer his help on re-installing the full code gen feature.
Gert,I just checked in the code generator. It is already adapted to the new maven build structure.You can find the generator code (with the Velocity template) in the /maven/build-tools module.I tested the codegen with the core/api module where I already added it to the
pom.xmlBy default code generation is turned off during a normal build. You can try it out with mvn compile -P regenerate-component-codePlease look at these open tasks:1. add code generation feature to tomahawk module
2. look for manually changed code parts that are now incompatible to regeneration i.e. generate code and do some svn diffing to find dangerous generated code part modifications3. revert and check in trivial (whitespace) changes that happened manually some time ago. The goal is to have a state where code (re)generation does not change anything with current code state.
4. Write a Wiki page HowToGenerateComponentCodePartsFor 2. and 3. we should wait for the 1.1.2 release to be out - which hopefully can happen during the next days.Thanks,Manfred
On 4/13/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Werner,Look at the component classes. Everything between the BEGIN and END GENERATED CODE markers was generated by a Velocity template from the according component xml files.In a few minutes I will checkin the reborn codegenerator - stay tuned.
ManfredOn 4/13/06,
Werner Punz [EMAIL PROTECTED] wrote:

Manfred Geiler schrieb: Ok, I just spent a few minutes and found the old codegenerator on the attic. Will try to integrate it into current maven structure. Please stay tuned! Thanks,
ManfredManfred, just a question, what was the scope of the old codegenerator,does it generated boilerplate code for the components?

Re: Puzzled about generated code

On 4/13/06, Werner Punz [EMAIL PROTECTED] wrote:
Manfred Geiler schrieb: Werner, Look at the component classes. Everything between the BEGIN and END GENERATED CODE markers was generated by a Velocity template from the according component xml files.
 In a few minutes I will checkin the reborn codegenerator - stay tuned.Ah superb, I was looking for such a thing for a long time.I knew something was done back then for the wml stuff, but I never had
time to dig into it.Lovely stuff, will save a lot of timeand beware us of dangerous copy and paste errors that are very likely to happen when writing boring trivial code parts.Manfred

[jira] Created: (MYFACES-1282) sandbox inputSuggestAjax ignores onkeydown event

2006-04-13 Thread Juergen Melzer (JIRA)

sandbox inputSuggestAjax ignores onkeydown event


 Key: MYFACES-1282
 URL: http://issues.apache.org/jira/browse/MYFACES-1282
 Project: MyFaces Core
Type: Bug

  Components: General  
Versions: 1.1.2-SNAPSHOT
Reporter: Juergen Melzer
 Fix For: 1.1.2-SNAPSHOT


I created a field like:

s:inputSuggestAjax suggestedItemsMethod=#{editUser.getUserNames} 
id=stellvertreterUserID
value=#{editUser.activeSubstitute} 
onkeydown=alert('Hallo') 
onclick=alert('Hallo')/

But no javascript event are generated...


-- 
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

[jira] Created: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox

2006-04-13 Thread Sharath Reddy (JIRA)

New 'Outlook Menu'  type component for Sandbox
--

 Key: TOMAHAWK-250
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-250
 Project: MyFaces Tomahawk
Type: New Feature

Reporter: Sharath Reddy


This component provides 'Outlook menu' type of component for  MyFaces.

Features include:
1. Action and action listener can be specified for each menu option
2. Menu can be constructed dynamically from a backing bean as demonstrated in 
the example 

-- 
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

[jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox

2006-04-13 Thread Mario Ivankovits (JIRA)

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-250?page=comments#action_12374327 
] 

Mario Ivankovits commented on TOMAHAWK-250:
---

Adapted from the original component developed by Kevin Le 
(http://pragmaticobjects.com) does this mean you copied some source from there?
If so, what license was/is it?

Where did you have the icons from? Whats their license?

Would it be possible to use 
org.apache.myfaces.custom.navmenu.NavigationMenuItem to configure the 
component.
That way it could be an easy replacement and we should try to keep our 
configurations slick.

 New 'Outlook Menu'  type component for Sandbox
 --

  Key: TOMAHAWK-250
  URL: http://issues.apache.org/jira/browse/TOMAHAWK-250
  Project: MyFaces Tomahawk
 Type: New Feature

 Reporter: Sharath Reddy
  Attachments: patch.zip

 This component provides 'Outlook menu' type of component for  MyFaces.
 Features include:
 1. Action and action listener can be specified for each menu option
 2. Menu can be constructed dynamically from a backing bean as demonstrated in 
 the example 

-- 
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

[jira] Reopened: (TOBAGO-13) Remove org.apache.myfaces.tobago.el.VariableResolverImpl from faces-config and rename it to UserVariableResolverImpl

2006-04-13 Thread Bernd Bohmann (JIRA)

 [ http://issues.apache.org/jira/browse/TOBAGO-13?page=all ]
 
Bernd Bohmann reopened TOBAGO-13:
-


 Remove org.apache.myfaces.tobago.el.VariableResolverImpl from faces-config 
 and rename it to UserVariableResolverImpl
 

  Key: TOBAGO-13
  URL: http://issues.apache.org/jira/browse/TOBAGO-13
  Project: MyFaces Tobago
 Type: Bug

 Reporter: Bernd Bohmann
 Assignee: Bernd Bohmann
 Priority: Trivial
  Fix For: 1.0.7




-- 
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

[jira] Closed: (TOBAGO-13) Remove org.apache.myfaces.tobago.el.VariableResolverImpl from faces-config and rename it to UserVariableResolverImpl

2006-04-13 Thread Bernd Bohmann (JIRA)

 [ http://issues.apache.org/jira/browse/TOBAGO-13?page=all ]
 
Bernd Bohmann closed TOBAGO-13:
---

Resolution: Fixed

 Remove org.apache.myfaces.tobago.el.VariableResolverImpl from faces-config 
 and rename it to UserVariableResolverImpl
 

  Key: TOBAGO-13
  URL: http://issues.apache.org/jira/browse/TOBAGO-13
  Project: MyFaces Tobago
 Type: Task

 Reporter: Bernd Bohmann
 Assignee: Bernd Bohmann
 Priority: Trivial
  Fix For: 1.0.7




-- 
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

[jira] Commented: (TOMAHAWK-98) Tabs in panelTabbedPane are shown as buttons on IExplorer

2006-04-13 Thread Jan Hoeve (JIRA)

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-98?page=comments#action_12374329 
] 

Jan Hoeve commented on TOMAHAWK-98:
---

I also have this problem.
Specifically: one jsp file had that problem, an other one did not.

I compared those file and found one thing: in the 'broken' jsp, the f:form 
surrounding the panelTabbedPane did not have an id, while the other jsp did 
have one.

I added an id to the form in the first jsp, and bingo: my Internet explorer 
problem was gone.

Maybe you could verify this. 


 Tabs in panelTabbedPane are shown as buttons on IExplorer
 -

  Key: TOMAHAWK-98
  URL: http://issues.apache.org/jira/browse/TOMAHAWK-98
  Project: MyFaces Tomahawk
 Type: Bug

  Environment: Windows XP Professional SP2, IE 6.0 SP2, Exadel Studio 3.0.4
 Reporter: Javor Petkov
 Assignee: Thomas Spiegl


 Hello, 
 The tabs in panelTabbedPane are shown as buttons when using Internet Explorer 
 6.0 SP2 and the XP theme for the MyFaces 1.1.1 version. 
 Tested with IE 6.0 without updates - same behaviour, tabs shown as buttons - 
 more visible if the default XP theme is used.
 With Firefox tabs are fine (displayed as tabs).
 With version 1.0.9 of MyFaces and IE the tabs are also rendered fine so this 
 seems to be a new feature/bug in MyFaces 1.1.1.
 The problem is reproducible with the Tabbed Pane example of Exadel Studio 
 3.0.4.
 Mail me for screenshots if needed.
 Thanks for having a look :)

-- 
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

Re: [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox

2006-04-13 Thread sharath reddy

Hi Mario,

Kevin wrote the original version as a JSP tag. I
converted it into a JSF component. I sought and
received permission from Kevin by email to do this. It
is an almost complete code rewrite.

I dont know where Kevin got the original icons from. I
am copying him on the email, so maybe he can reply.

I suppose I can use NavigationMenuItem...but it is not
a good fit. The atttribute names dont match...Also,
every panel has a list of Icons, so I would have to
add an arrayList attribute to NavigationMenuItem.

I will look into it and get back to you.

Regards,
Sharath 

 




--- Mario Ivankovits (JIRA) dev@myfaces.apache.org
wrote:

 [

http://issues.apache.org/jira/browse/TOMAHAWK-250?page=comments#action_12374327
 ] 
 
 Mario Ivankovits commented on TOMAHAWK-250:
 ---
 
 Adapted from the original component developed by
 Kevin Le (http://pragmaticobjects.com) does this
 mean you copied some source from there?
 If so, what license was/is it?
 
 Where did you have the icons from? Whats their
 license?
 
 Would it be possible to use

org.apache.myfaces.custom.navmenu.NavigationMenuItem
 to configure the component.
 That way it could be an easy replacement and we
 should try to keep our configurations slick.
 
  New 'Outlook Menu'  type component for Sandbox
  --
 
   Key: TOMAHAWK-250
   URL:
 http://issues.apache.org/jira/browse/TOMAHAWK-250
   Project: MyFaces Tomahawk
  Type: New Feature
 
  Reporter: Sharath Reddy
   Attachments: patch.zip
 
  This component provides 'Outlook menu' type of
 component for  MyFaces.
  Features include:
  1. Action and action listener can be specified for
 each menu option
  2. Menu can be constructed dynamically from a
 backing bean as demonstrated in the example 
 
 -- 
 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
 
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox

2006-04-13 Thread sharath reddy

Hi Mario,

Ok, I see that NavigationMenuItems already has a List
attribute. I could probably use this. I can submit a
patch.

BTW, below is the license from the original files. I
am sorry if I seem to be a bit naive about license
issues, I assumed that since I corresponded with Le
and obtained his permission, there would not be any
issues.

/*
 * Created on Dec 19, 2004
 *
 * Copyright (c) 2005, Pragmatic Objects - Kevin H. Le
 * All rights reserved.
 * Redistribution and use in source and binary forms,
with or without
 * modification, are permitted provided that the
following conditions are met:
 *
 * 1. Redistributions of source code must retain the
above copyright notice,
 * this list of conditions and the following
disclaimer.
 * 2. Redistributions in binary form must reproduce
the above copyright notice,
 * this list of conditions and the following
disclaimer in the documentation
 * and/or other materials provided with the
distribution.
 * 3. Neither the name of the Pragmatic Objects nor
Kevin H. Le nor the
 * names of its contributors may be used to endorse or
promote products derived
 * from this software without specific prior written
permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
AND CONTRIBUTORS AS IS
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */








--- Mario Ivankovits (JIRA) dev@myfaces.apache.org
wrote:

 [

http://issues.apache.org/jira/browse/TOMAHAWK-250?page=comments#action_12374327
 ] 
 
 Mario Ivankovits commented on TOMAHAWK-250:
 ---
 
 Adapted from the original component developed by
 Kevin Le (http://pragmaticobjects.com) does this
 mean you copied some source from there?
 If so, what license was/is it?
 
 Where did you have the icons from? Whats their
 license?
 
 Would it be possible to use

org.apache.myfaces.custom.navmenu.NavigationMenuItem
 to configure the component.
 That way it could be an easy replacement and we
 should try to keep our configurations slick.
 
  New 'Outlook Menu'  type component for Sandbox
  --
 
   Key: TOMAHAWK-250
   URL:
 http://issues.apache.org/jira/browse/TOMAHAWK-250
   Project: MyFaces Tomahawk
  Type: New Feature
 
  Reporter: Sharath Reddy
   Attachments: patch.zip
 
  This component provides 'Outlook menu' type of
 component for  MyFaces.
  Features include:
  1. Action and action listener can be specified for
 each menu option
  2. Menu can be constructed dynamically from a
 backing bean as demonstrated in the example 
 
 -- 
 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
 
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[al] license question [was [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox]

sharath reddy schrieb:
 Ok, I see that NavigationMenuItems already has a List
 attribute. I could probably use this. I can submit a
 patch.
   
Great!

 BTW, below is the license from the original files. I
 am sorry if I seem to be a bit naive about license
 issues
No problem, licensing stuff is odd ;-)

 , I assumed that since I corresponded with Le
 and obtained his permission, there would not be any
 issues.
   
The question is if Le was aware that you would change the license.

What to do next? How can we ensure that there is no license problem?
Do Le and Sharath have to sign a CLA?
 /*
  * Created on Dec 19, 2004
  *
  * Copyright (c) 2005, Pragmatic Objects - Kevin H. Le
  * All rights reserved.
  * Redistribution and use in source and binary forms,
 with or without
  * modification, are permitted provided that the
 following conditions are met:
  *
  * 1. Redistributions of source code must retain the
 above copyright notice,
  * this list of conditions and the following
 disclaimer.
  * 2. Redistributions in binary form must reproduce
 the above copyright notice,
  * this list of conditions and the following
 disclaimer in the documentation
  * and/or other materials provided with the
 distribution.
  * 3. Neither the name of the Pragmatic Objects nor
 Kevin H. Le nor the
  * names of its contributors may be used to endorse or
 promote products derived
  * from this software without specific prior written
 permission.
  *
  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
 AND CONTRIBUTORS AS IS
  * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
 BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 FOR A PARTICULAR PURPOSE
  * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 OWNER OR CONTRIBUTORS BE
  * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 SPECIAL, EXEMPLARY, OR
  * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
 TO, PROCUREMENT OF
  * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
 PROFITS; OR BUSINESS
  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 LIABILITY, WHETHER IN
  * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
 NEGLIGENCE OR OTHERWISE)
  * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 EVEN IF ADVISED OF THE
  * POSSIBILITY OF SUCH DAMAGE.
  */

Ciao,
Mario

JavaScript set values and model update

2006-04-13 Thread Alexander Panzhin


I have a problem with JavaScript set values.
t:selectOneMenu id=moduleSelect forceId=true value=#{search.module}
f:selectItems value=#{search.modules} /
/t:selectOneMenu

Than I add options to this select menu via js.
  var a = document.getElementById(moduleSelect).options;
  a[0] = new Option(,, false);
and so on...

My #{search.modules} also returns a SelectItem list(when appropriate).
But the problem is unless #{search.modules} is not empty, whatever i 
choose update my model with that data.


Is there anything that I'm missing here?

I use Facelets/MyFaces.


smime.p7s
Description: S/MIME Cryptographic Signature

dataScroller with newspaperTable?

2006-04-13 Thread Marcus Beyer


hello all,

Is it possible to apply a dataScroller on a newspaperTable?

I tried this with newspaperColumns=2 but got only one column.

I asked the people from the user mailing list with no result :(

Please help.

thanx!
Marcus



t:newspaperTable id=at newspaperColumns=2
rows=#{articleHandler.numberRowsPerPage}
value=#{articleHandler.currentRowSet.wrappedData} var=article
f:facet name=spacerf:verbatim#160;/f:verbatim/f:facet
h:column id=col
h:outputText value=#{article.title} id=title /
/h:column
/t:newspaperTable

t:dataScroller for=at
style=margin-top: 1em
fastStep=20
pageCountVar=pageCount
pageIndexVar=pageIndex
paginator=true
paginatorMaxPages=20
paginatorTableClass=paginator
paginatorActiveColumnClass=paginatorActiveColumn
renderFacetsIfSinglePage=false

/t:dataScroller

[jira] Created: (TOMAHAWK-251) previousRowDataVar is not saved/restored

2006-04-13 Thread Chris Rudd (JIRA)

previousRowDataVar is not saved/restored


 Key: TOMAHAWK-251
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-251
 Project: MyFaces Tomahawk
Type: Bug

  Components: Extended Datatable  
Versions: 1.1.1
Reporter: Chris Rudd


The previousRowDatavar is not managed by the saveState/restoreState methods. 
This results in the value being null on all subsequent requests that restore 
the view. 

Note: if you use value binding it works as UIComponentBase manages the 
save/restore of all value bindings.

-- 
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

RE: default AutoScroll setting depends on Tomahawk

2006-04-13 Thread Lyon, Chad S.


Mario,

You never got back to me on this.  What do you think?  I am willing to help
add this functionality to the sandbox focus component if that is where you
think it should go but I think it should go with the auto-scrolling stuff
for accessibility reasons (i.e. no mouse).  You are the more experienced
Myfaces developer.  Let me know.
 
 
Chad Lyon
Application Software Developer
Science Applications International Corporation (SAIC)

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 12, 2006 11:25 AM
To: MyFaces Development
Subject: RE: default AutoScroll setting depends on Tomahawk

Sorry for being ignorant, but whats the value for the user to have the
focus reset on the last action component?

Let's say you are tabbing through the controls on a shopping cart page (in a
mouse-less world).  After changing the number of items in an inputText field
you tab to a button that, for example, updates your shopping cart.  You hit
space bar to press the button (fire the action), the page reloads and your
focus is back at the top.  In a similar thick client app you would retain
focus to the button you just pressed.
 
  
Chad Lyon
Application Software Developer
Science Applications International Corporation (SAIC)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Mario Ivankovits
Sent: Wednesday, April 12, 2006 9:59 AM
To: MyFaces Development
Subject: Re: default AutoScroll setting depends on Tomahawk

Hi
 You seem like the person to approve the patch I wrote for auto-focus.
Sorry for being ignorant, but whats the value for the user to have the
focus reset on the last action component?
Could you please explain this a little bit for me.


If, I would like to have the focus set on the first component caused a
validation error, else the focus should be on the first inputable
component on the page.
For sure, both scenarios can be solved by enhancing the focus component.


Ciao,
Mario

Re: [al] license question [was [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox]

On 4/13/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
   * Copyright (c) 2005, Pragmatic Objects - Kevin H. Le

It looks like a pretty standard BSD license.

 Do Le and Sharath have to sign a CLA?

Yes, it would be best if Le signed a CLA and agreed to release this
under the Apache 2.0 license.  Otherwise, we'll have to carry forward
the Pragmatic Objects BSD license, which is extra work.  Depending on
the size of the contribution, it's not necessarily worthwhile.  
Sharath should also sign a CLA if this is a significant contribution
-- it's currently unclear how much of the work is from Sharath and how
much is from Le.

Re: [al] license question [was [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox]

2006-04-13 Thread Dennis Byrne

What to do next? How can we ensure that there is no license problem?
Do Le and Sharath have to sign a CLA?

To play it safe, yes ( as well as Pragmatic Objects ).  The apache main site 
has information on corporate intellectual property contributions.

Dennis Byrne

Re: default AutoScroll setting depends on Tomahawk

Hi Lyon!
 You never got back to me on this.
Yes, sorry!

 What do you think?  I am willing to help
 add this functionality to the sandbox focus component if that is where you
 think it should go but I think it should go with the auto-scrolling stuff
 for accessibility reasons (i.e. no mouse).
I would be more happy if we manage to put it into the focus component.
For this to work we have to create a way so components can register
additional (global) fields with form/link/button.
A more generic way like adding every possible function again and again
into the core.

The focus component then can register with them and tell them wich
javascript/field/wathever to render if e.g. it is configured with
t:focus captureActionFocus=true/

We can rename our DummyFormLinkRenderer and DummyFormButtonRenderer in
tomahawk to something like ExtendedLinkRenderer and ExtendedButtonRender
and also create an ExtendedFormRenderer in tomahawk.

The registry could be a request bean where we have to outline its
interface and possibilities.


What do you think?

Ciao,
Mario

[jira] Created: (TOMAHAWK-252) tree2 table, td for spacing/navigation inherits CSS styles

2006-04-13 Thread Bill Schneider (JIRA)

tree2 table, td for spacing/navigation inherits CSS styles
--

 Key: TOMAHAWK-252
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-252
 Project: MyFaces Tomahawk
Type: Improvement

  Components: Tree2  
Versions: 1.1.1
 Environment: tree2 uses table and td to implement spacing and placement of 
the tree branch lines, folder images etc.

this is problematic if the t:tree2 is within another table, as the cells may 
inherit CSS styles from the parent table class= resulting in 
undesireable borders or padding around the tree navigation components despite 
table border=0 cellpadding=0  etc.

suggested solution is to use img instead for fixed width placeholders instead 
of a nested table.
Reporter: Bill Schneider




-- 
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

Re: default AutoScroll setting depends on Tomahawk

On 4/13/06, Lyon, Chad S. [EMAIL PROTECTED] wrote:
 I am willing to help
 add this functionality to the sandbox focus component if that is where you
 think it should go but I think it should go with the auto-scrolling stuff
 for accessibility reasons (i.e. no mouse).

I think it's fine for it to work like auto-scrolling does.   However,
I think it'd also be good if we either added a focus attribute for
Tomahawk components, or -- and I think this would be more versatile --
included the focus component as part of this process, so that a page
designer could change the focus behavior without writing javascript.

I'd also like to see something similar for autoscroll, but with my
limited javascript knowledge, I was never able to get autoscrolling to
be controllable.


On 4/13/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
 For this to work we have to create a way so components can register
 additional (global) fields with form/link/button.
 A more generic way like adding every possible function again and again
 into the core.

Mario, this is a good idea!   The Jenia4Faces developers were asking
me about this same functionality yesterday.All I could suggest was
that they scan the component tree for the form and programmically add
a hidden input field to the component tree.   I have no idea how
practical that process would be.

[jira] Created: (MYFACES-1283) JavaScript error on AccordionPanel

2006-04-13 Thread JIRA

JavaScript error on AccordionPanel
--

 Key: MYFACES-1283
 URL: http://issues.apache.org/jira/browse/MYFACES-1283
 Project: MyFaces Core
Type: Bug

  Components: General  
Versions: 1.1.0, 1.0.9m9, 1.1.1, 1.1.2-SNAPSHOT
Reporter: Rogério Pereira Araújo
Priority: Blocker
 Fix For: 1.1.2-SNAPSHOT


When i load a page with AccordionPanel i get these errors:

Error: {expandedBg:#63699c, hoverBg:#63699c, collapsedBg:#6b79a5, 
expandedTextColor:#ff, expandedFontWeight:bold, 
hoverTextColor:#ff, collapsedTextColor:#ced7ef, 
collapsedFontWeight:normal, hoverTextColor:#ff, borderColor:#1f669b, 
panelHeight:200, onHideTab:null, onShowTab:null}.extend is not a function
source file: 
http://localhost:8080/myfaces-example-sandbox/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11449359/accordion.HtmlAccordionPanelRenderer/customRico.js
Line: 50

Error: {expandedBg:#63699c, hoverBg:#63699c, collapsedBg:#6b79a5, 
expandedTextColor:#ff, expandedFontWeight:bold, 
hoverTextColor:#ff, collapsedTextColor:#ced7ef, 
collapsedFontWeight:normal, hoverTextColor:#ff, borderColor:#1f669b, 
panelHeight:200, closedPanelHeight:50, useRealHeight:true, onHideTab:null, 
onShowTab:null}.extend is not a function
source file: 
http://localhost:8080/myfaces-example-sandbox/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11449359/accordion.HtmlAccordionPanelRenderer/customRico.js
Line: 276

-- 
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

[jira] Updated: (MYFACES-1283) JavaScript error on AccordionPanel

2006-04-13 Thread JIRA

 [ http://issues.apache.org/jira/browse/MYFACES-1283?page=all ]

Rogério Pereira Araújo updated MYFACES-1283:


Status: Patch Available  (was: Open)

 JavaScript error on AccordionPanel
 --

  Key: MYFACES-1283
  URL: http://issues.apache.org/jira/browse/MYFACES-1283
  Project: MyFaces Core
 Type: Bug

   Components: General
 Versions: 1.1.0, 1.0.9m9, 1.1.1, 1.1.2-SNAPSHOT
 Reporter: Rogério Pereira Araújo
 Priority: Blocker
  Fix For: 1.1.2-SNAPSHOT
  Attachments: customRico.diff

 When i load a page with AccordionPanel i get these errors:
 Error: {expandedBg:#63699c, hoverBg:#63699c, collapsedBg:#6b79a5, 
 expandedTextColor:#ff, expandedFontWeight:bold, 
 hoverTextColor:#ff, collapsedTextColor:#ced7ef, 
 collapsedFontWeight:normal, hoverTextColor:#ff, 
 borderColor:#1f669b, panelHeight:200, onHideTab:null, 
 onShowTab:null}.extend is not a function
 source file: 
 http://localhost:8080/myfaces-example-sandbox/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11449359/accordion.HtmlAccordionPanelRenderer/customRico.js
 Line: 50
 Error: {expandedBg:#63699c, hoverBg:#63699c, collapsedBg:#6b79a5, 
 expandedTextColor:#ff, expandedFontWeight:bold, 
 hoverTextColor:#ff, collapsedTextColor:#ced7ef, 
 collapsedFontWeight:normal, hoverTextColor:#ff, 
 borderColor:#1f669b, panelHeight:200, closedPanelHeight:50, 
 useRealHeight:true, onHideTab:null, onShowTab:null}.extend is not a function
 source file: 
 http://localhost:8080/myfaces-example-sandbox/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11449359/accordion.HtmlAccordionPanelRenderer/customRico.js
 Line: 276

-- 
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

[jira] Commented: (MYFACES-1281) Unable to write and restore serialized views

2006-04-13 Thread sean schofield (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1281?page=comments#action_12374370 
] 

sean schofield commented on MYFACES-1281:
-

My patch still does not fix TCK problem.  Without getting into too much of an 
NDA area here, lets just say the TCK makes two different requests to test this 
and that its unaware of our view sequence produced during rendering.  My 
proposed solution is to store the sequence of the last view accessed in the 
session so that if there is a problem obtaining the sequence it can default to 
this.  I don't think this will break existing functionality but I'm hoping to 
hear more from the serialized view experts out there.

 Unable to write and restore serialized views
 

  Key: MYFACES-1281
  URL: http://issues.apache.org/jira/browse/MYFACES-1281
  Project: MyFaces Core
 Type: Bug

   Components: JSR-127
 Versions: 1.1.2-SNAPSHOT
 Reporter: sean schofield
 Priority: Blocker
  Fix For: 1.1.2-SNAPSHOT
  Attachments: one_line_fix.patch

 TCK testing turned up an apparent issue with restoring serialized views.  
 Because of the NDA I can't get into the specific details of the test but I 
 have added my own unit test to core-impl that demonstrates the problem.  We 
 need to fix this ASAP.

-- 
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

Re: [IMPORTANT] Major blocker issue: MYFACES-1281

This issue still isn't fixed.  Please review my latest JIRA comments
on the proposed solution.  This issue is our top priority right now.

Sean

On 4/12/06, Sean Schofield [EMAIL PROTECTED] wrote:
 BTW, it appears i did not commit the test last night or the fix today.
  I just committed both to the branch.

 Sean

 On 4/12/06, Sean Schofield [EMAIL PROTECTED] wrote:
  Ok so this is how things work outside of unit tests.  I am committing
  a fix that I think should work for the unit test (and TCK) and still
  leave the existing functionality the way it is (which is presumably
  good b/c we've heard no complaints on this.)
 
  Sean
 
  On 4/12/06, Dennis Byrne [EMAIL PROTECTED] wrote:
   MyFaces looks for a parameter called jsf_sequence .  Do a few post backs 
   on any form page in the example app and you'll see this incremented.  
   This is how the impl keeps track of which view to associate w/ each
  
   IF YOU KNOW ANYTHING MORE ON THIS, HELP.
  
   Dennis Byrne
  
   -Original Message-
   From: Sean Schofield [mailto:[EMAIL PROTECTED]
   Sent: Wednesday, April 12, 2006 11:58 AM
   To: 'MyFaces Development'
   Subject: Re: [IMPORTANT] Major blocker issue: MYFACES-1281
   
   Still waiting for some help on this issue.  Come on MyFaces committers
   lets get this one figured out.  You don't need the TCK to fix this.
   Just make the unit test work and help explain how it works (if it ever
   worked) in the standard non-unit test case.
   
   Sean
   
   On 4/11/06, Sean Schofield [EMAIL PROTECTED] wrote:
There is an outstanding issue that is preventing us from passing the
TCK.  Without this we cannot release a JSF 1.1 certified release.  We
could use everyone's help in tracking this down and resolving ASAP.
We need to get on with the 1.1.2 release.
   
Sean
   
ps. More frequent releases should help reduce the number of suprise
TCK failures per release.  Also more unit tests will be helpful here.

[jira] Updated: (MYFACES-821) Usage of request attributes for caching

2006-04-13 Thread Anonymous (JIRA)

 [ http://issues.apache.org/jira/browse/MYFACES-821?page=all ]

 updated MYFACES-821:
-

Status: Patch Available  (was: Open)

 Usage of request attributes for caching
 ---

  Key: MYFACES-821
  URL: http://issues.apache.org/jira/browse/MYFACES-821
  Project: MyFaces Core
 Type: Bug

 Versions: 1.1.0
  Environment: liferay 3.6.1
 Reporter: Michael Lipp
 Assignee: Stan Silvert


 JspStateManagerImpl (and maybe other classes) uses request attributes for 
 caching state. This causes a wrong view to be used if there is more than one 
 JSF-based portlet on a single page. MyFaces saves the serialized view of the 
 first portlet on the page as a request attribute. To avoid re-serialization, 
 MyFaces subsequently checks if there already is a request attribute with a 
 serialized view. As request attributes are not scoped to a single portlet 
 (the portlet specification does not require this), the serialized view of the 
 first portlet will be found and used by the second portlet.
 This usage of request attributes may also be the cause of MYFACES-549.
 As JSF, of course, does not need to know about the portlet environment, it 
 cannot be required that MyFaces saves such information per view, e.g. by 
 prepending the viewId to the key for the request attribute (although this 
 would solve the problem). IMHO any request attributes added during 
 lifecycle.render() should be removed after lifecycle() render by the portlet 
 bridge. (The same applies to request attributes added during 
 lifecycle.execute(), but these should also be re-added before 
 lifecycle.render().) I have implemented this in my portlet bridge as a 
 workaround.

-- 
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

[jira] Commented: (MYFACES-1281) Unable to write and restore serialized views

2006-04-13 Thread Mario Ivankovits (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1281?page=comments#action_12374380 
] 

Mario Ivankovits commented on MYFACES-1281:
---

I'll have a look at it now - even if I am not a serialized view expert ;-)

 Unable to write and restore serialized views
 

  Key: MYFACES-1281
  URL: http://issues.apache.org/jira/browse/MYFACES-1281
  Project: MyFaces Core
 Type: Bug

   Components: JSR-127
 Versions: 1.1.2-SNAPSHOT
 Reporter: sean schofield
 Priority: Blocker
  Fix For: 1.1.2-SNAPSHOT
  Attachments: one_line_fix.patch

 TCK testing turned up an apparent issue with restoring serialized views.  
 Because of the NDA I can't get into the specific details of the test but I 
 have added my own unit test to core-impl that demonstrates the problem.  We 
 need to fix this ASAP.

-- 
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

Re: Provide Patch / Cancel Patch

Sorry, I got mixed up while fixing the workflow.  There are two
separate concepts: 1.) workflow, 2.) workflow scheme.  I had only
changed the scheme but it was pointing to the wrong workflow.  It
should be fixed now.

Sean

On 4/13/06, Volker Weber [EMAIL PROTECTED] wrote:
 Hi Sean,

 are you sure? It looks like just a anonymous user triggers this, see

 http://issues.apache.org/jira/browse/TOBAGO-54?page=all



 Regards,
   Volker


 Sean Schofield wrote:
  Done.  Users must have the same permissions as for Create Issue (which
  is to say they must be logged in.)
 
  Sean
 
  On 3/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 
 I'm wondering if it'd be possible to restrict Provide Patch to
 logged-in users.
 It's annoying when an anonymous user triggers this with a patch
 because there's no way to identify them in order to educate them as to
 why it was the wrong thing to do.
 
 On 3/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 
 Is there any way to have the JIRA notification mail state when one of
 these buttons was pushed?
 
 Right now we only get the following (Anon said there was a patch; I
 cancelled the process because there wasn't one).
 
 
 Anonymous (JIRA)
 [ http://issues.apache.org/jira/browse/TOMAHAWK-134?page=all ]
  updated TOMAHAWK-134:
 
 Mike Kienenberger (JIRA)
 [ http://issues.apache.org/jira/browse/TOMAHAWK-134?page=all ]
 Mike Kienenberger updated TOMAHAWK-134:
 
 
 

 --
 Don't answer to From: address!
 Mail to this account are droped if not recieved via mailinglist.
 To contact me direct create the mail address by
 concatenating my forename to my senders domain.

[jira] Created: (TOMAHAWK-253) Dummy form code must call StateManager.saveSerializedView() for server-side state saving

2006-04-13 Thread Adam Winer (JIRA)

Dummy form code must call StateManager.saveSerializedView() for server-side 
state saving


 Key: TOMAHAWK-253
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-253
 Project: MyFaces Tomahawk
Type: Bug

Versions: 1.1.2-SNAPSHOT
 Environment: Generic issue.
Reporter: Adam Winer


The current dummy form code in DummyFormUtils has a block that reads:

if (stateManager.isSavingStateInClient(facesContext))
{
//render state parameters
//TODO: Optimize saveSerializedView call, because serialized view 
is built twice!
StateManager.SerializedView serializedView = 
stateManager.saveSerializedView(facesContext);
stateManager.writeState(facesContext, serializedView);
}
else
{
writer.startElement(HTML.INPUT_ELEM, null);

writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.TYPE_ATTR,
 org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_TYPE_HIDDEN, 
null);
writer.writeAttribute(HTML.NAME_ATTR, 
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.SEQUENCE_PARAM, 
null);

writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.VALUE_ATTR,
 
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getViewSequence(facesContext),
 null);

writer.endElement(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_ELEM);
}

Note that stateManager.saveSerializedView() is only called for client-side 
state saving.

This means that the dummy form code never actually gets around to calling 
stateManager.saveSerializedView(), so unless someone else has called this 
method, the view never actually gets saved in the session.  This is breaking 
the latest release of Facelets (1.1.5), which has added optimizations that 
avoid unnecessary calls to the StateManager.

Simple fix:   haul 
StateManager.SerializedView serializedView = 
stateManager.saveSerializedView(facesContext);
... out of the if block.

Ideally, this code should be refactored so that the server-side code is also 
calling StateManager.writeState() too - it's a significant problem that 
DummyFormUtils has hardcoded knowledge of how the StateManager works.

-- 
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

[jira] Updated: (TOMAHAWK-253) Dummy form code must call StateManager.saveSerializedView() for server-side state saving

2006-04-13 Thread Adam Winer (JIRA)

 [ http://issues.apache.org/jira/browse/TOMAHAWK-253?page=all ]

Adam Winer updated TOMAHAWK-253:


Status: Patch Available  (was: Open)

 Dummy form code must call StateManager.saveSerializedView() for server-side 
 state saving
 

  Key: TOMAHAWK-253
  URL: http://issues.apache.org/jira/browse/TOMAHAWK-253
  Project: MyFaces Tomahawk
 Type: Bug

 Versions: 1.1.2-SNAPSHOT
  Environment: Generic issue.
 Reporter: Adam Winer


 The current dummy form code in DummyFormUtils has a block that reads:
 if (stateManager.isSavingStateInClient(facesContext))
 {
 //render state parameters
 //TODO: Optimize saveSerializedView call, because serialized view 
 is built twice!
 StateManager.SerializedView serializedView = 
 stateManager.saveSerializedView(facesContext);
 stateManager.writeState(facesContext, serializedView);
 }
 else
 {
 writer.startElement(HTML.INPUT_ELEM, null);
 
 writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.TYPE_ATTR,
  org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_TYPE_HIDDEN, 
 null);
 writer.writeAttribute(HTML.NAME_ATTR, 
 org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.SEQUENCE_PARAM, 
 null);
 
 writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.VALUE_ATTR,
  
 org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getViewSequence(facesContext),
  null);
 
 writer.endElement(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_ELEM);
 }
 Note that stateManager.saveSerializedView() is only called for client-side 
 state saving.
 This means that the dummy form code never actually gets around to calling 
 stateManager.saveSerializedView(), so unless someone else has called this 
 method, the view never actually gets saved in the session.  This is breaking 
 the latest release of Facelets (1.1.5), which has added optimizations that 
 avoid unnecessary calls to the StateManager.
 Simple fix:   haul 
 StateManager.SerializedView serializedView = 
 stateManager.saveSerializedView(facesContext);
 ... out of the if block.
 Ideally, this code should be refactored so that the server-side code is also 
 calling StateManager.writeState() too - it's a significant problem that 
 DummyFormUtils has hardcoded knowledge of how the StateManager works.

-- 
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

Any status update on the Subversion repos?

2006-04-13 Thread Jonas Jacobi





Hi Craig,

It is now three weeks since the announcement of the new adffaces-xxx
mailing lists. I know you are busy, but do you have a status update on
the creation of the Subversion repository
for these components? 

Thanks
- Jonas
-- 
Author: Pro JSF and
Ajax: Building Rich Internet Components
Blog: 
http://www.orablogs.com/jjacobi

[jira] Commented: (TOMAHAWK-253) Dummy form code must call StateManager.saveSerializedView() for server-side state saving

2006-04-13 Thread Adam Winer (JIRA)

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-253?page=comments#action_12374383 
] 

Adam Winer commented on TOMAHAWK-253:
-

As with my last issue, no true patch, but a one-line fix provided in the bug 
text.

 Dummy form code must call StateManager.saveSerializedView() for server-side 
 state saving
 

  Key: TOMAHAWK-253
  URL: http://issues.apache.org/jira/browse/TOMAHAWK-253
  Project: MyFaces Tomahawk
 Type: Bug

 Versions: 1.1.2-SNAPSHOT
  Environment: Generic issue.
 Reporter: Adam Winer


 The current dummy form code in DummyFormUtils has a block that reads:
 if (stateManager.isSavingStateInClient(facesContext))
 {
 //render state parameters
 //TODO: Optimize saveSerializedView call, because serialized view 
 is built twice!
 StateManager.SerializedView serializedView = 
 stateManager.saveSerializedView(facesContext);
 stateManager.writeState(facesContext, serializedView);
 }
 else
 {
 writer.startElement(HTML.INPUT_ELEM, null);
 
 writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.TYPE_ATTR,
  org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_TYPE_HIDDEN, 
 null);
 writer.writeAttribute(HTML.NAME_ATTR, 
 org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.SEQUENCE_PARAM, 
 null);
 
 writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.VALUE_ATTR,
  
 org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getViewSequence(facesContext),
  null);
 
 writer.endElement(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_ELEM);
 }
 Note that stateManager.saveSerializedView() is only called for client-side 
 state saving.
 This means that the dummy form code never actually gets around to calling 
 stateManager.saveSerializedView(), so unless someone else has called this 
 method, the view never actually gets saved in the session.  This is breaking 
 the latest release of Facelets (1.1.5), which has added optimizations that 
 avoid unnecessary calls to the StateManager.
 Simple fix:   haul 
 StateManager.SerializedView serializedView = 
 stateManager.saveSerializedView(facesContext);
 ... out of the if block.
 Ideally, this code should be refactored so that the server-side code is also 
 calling StateManager.writeState() too - it's a significant problem that 
 DummyFormUtils has hardcoded knowledge of how the StateManager works.

-- 
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

ADF Faces and JIRA

Is there a reason why we can't use the custom MyFaces JIRA workflow
for the ADF Faces project?  We have a few little extras that are nice
to have and this will ultimately make it easier to assimilate the ADF
project when the time comes.

Sean

ps. I'm happy to change it if this is desired.

Re: ADF Faces and JIRA

I'd definitely want to use the same workflow.

-- Adam


On 4/13/06, Sean Schofield [EMAIL PROTECTED] wrote:
 Is there a reason why we can't use the custom MyFaces JIRA workflow
 for the ADF Faces project?  We have a few little extras that are nice
 to have and this will ultimately make it easier to assimilate the ADF
 project when the time comes.

 Sean

 ps. I'm happy to change it if this is desired.

[jira] Commented: (MYFACES-1281) Unable to write and restore serialized views

2006-04-13 Thread Mario Ivankovits (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1281?page=comments#action_12374388 
] 

Mario Ivankovits commented on MYFACES-1281:
---

Ok, looks like I got it.

It already falls back to the sessionmap if the sequence cant be found in the 
request, the problem ist, that the FIRST sequence isnt stored in the session 
map (subsequent will - so in fact this IS ab BUG)

I dont like the code around the sequence number, but its not the time to 
rewrite it ;-) , so I made a quick hack which also saves the sequence in the 
session on the first request.

 Unable to write and restore serialized views
 

  Key: MYFACES-1281
  URL: http://issues.apache.org/jira/browse/MYFACES-1281
  Project: MyFaces Core
 Type: Bug

   Components: JSR-127
 Versions: 1.1.2-SNAPSHOT
 Reporter: sean schofield
 Priority: Blocker
  Fix For: 1.1.2-SNAPSHOT
  Attachments: one_line_fix.patch

 TCK testing turned up an apparent issue with restoring serialized views.  
 Because of the NDA I can't get into the specific details of the test but I 
 have added my own unit test to core-impl that demonstrates the problem.  We 
 need to fix this ASAP.

-- 
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

[jira] Updated: (MYFACES-821) Usage of request attributes for caching

2006-04-13 Thread Mike Kienenberger (JIRA)

 [ http://issues.apache.org/jira/browse/MYFACES-821?page=all ]

Mike Kienenberger updated MYFACES-821:
--

Status: Open  (was: Patch Available)

 Usage of request attributes for caching
 ---

  Key: MYFACES-821
  URL: http://issues.apache.org/jira/browse/MYFACES-821
  Project: MyFaces Core
 Type: Bug

 Versions: 1.1.0
  Environment: liferay 3.6.1
 Reporter: Michael Lipp
 Assignee: Stan Silvert


 JspStateManagerImpl (and maybe other classes) uses request attributes for 
 caching state. This causes a wrong view to be used if there is more than one 
 JSF-based portlet on a single page. MyFaces saves the serialized view of the 
 first portlet on the page as a request attribute. To avoid re-serialization, 
 MyFaces subsequently checks if there already is a request attribute with a 
 serialized view. As request attributes are not scoped to a single portlet 
 (the portlet specification does not require this), the serialized view of the 
 first portlet will be found and used by the second portlet.
 This usage of request attributes may also be the cause of MYFACES-549.
 As JSF, of course, does not need to know about the portlet environment, it 
 cannot be required that MyFaces saves such information per view, e.g. by 
 prepending the viewId to the key for the request attribute (although this 
 would solve the problem). IMHO any request attributes added during 
 lifecycle.render() should be removed after lifecycle() render by the portlet 
 bridge. (The same applies to request attributes added during 
 lifecycle.execute(), but these should also be re-added before 
 lifecycle.render().) I have implemented this in my portlet bridge as a 
 workaround.

-- 
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

[jira] Updated: (TOMAHAWK-210) Would be recommendable to add to a new attribute to tag t:panelTab that allows to disabled a certain tab

2006-04-13 Thread Mike Kienenberger (JIRA)

 [ http://issues.apache.org/jira/browse/TOMAHAWK-210?page=all ]

Mike Kienenberger updated TOMAHAWK-210:
---

Status: Open  (was: Patch Available)

 Would be recommendable to add to a new attribute to tag t:panelTab that 
 allows to disabled a certain tab
 --

  Key: TOMAHAWK-210
  URL: http://issues.apache.org/jira/browse/TOMAHAWK-210
  Project: MyFaces Tomahawk
 Type: New Feature

   Components: Tabbed Pane
  Environment: Windows XP
 Jboss 4.0.3SP1
 Tomahawk 1.1.1
 Reporter: Jorge Rodríguez Pedrianes
 Priority: Minor


 Hello, I have been working with the component Tabbe Pane and have seen that 
 it has the possibility of disabled a certain tab taking care of role of user. 
  Although this very is limited, this could also be done to with an attribute 
 in tag  t:panelTab/, for example with one with the name disabled that 
 you can put to him a boolean or one EL.
 For Example:
t:panelTab .  disabled=true /  or  t:panelTab 
 .  disabled=#{backingBean.disabled} /

-- 
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

Re: Provide Patch / Cancel Patch

On 4/13/06, Sean Schofield [EMAIL PROTECTED] wrote:
 Sorry, I got mixed up while fixing the workflow.  There are two
 separate concepts: 1.) workflow, 2.) workflow scheme.  I had only
 changed the scheme but it was pointing to the wrong workflow.  It
 should be fixed now.

I'm able to cancel patches again.  I haven't tested to insure that
anonymous users can't provide them, but I'm sure some anonymous user
will step forward and let us know if it's still possible :)

Re: ADF Faces and JIRA

Done.  I noticed the project has its own permissions and notifications
schemes as well.  Notification probably makes sense because of the
different mailing lists.  I'll look at permissions at some future
point.

Sean

On 4/13/06, Adam Winer [EMAIL PROTECTED] wrote:
 I'd definitely want to use the same workflow.

 -- Adam


 On 4/13/06, Sean Schofield [EMAIL PROTECTED] wrote:
  Is there a reason why we can't use the custom MyFaces JIRA workflow
  for the ADF Faces project?  We have a few little extras that are nice
  to have and this will ultimately make it easier to assimilate the ADF
  project when the time comes.
 
  Sean
 
  ps. I'm happy to change it if this is desired.

Re: [IMPORTANT] Major blocker issue: MYFACES-1281

What about Mario's fix 2 hours ago? (see Jira)ManfredOn 4/13/06, Sean Schofield [EMAIL PROTECTED]
 wrote:This issue still isn't fixed.Please review my latest JIRA comments
on the proposed solution.This issue is our top priority right now.SeanOn 4/12/06, Sean Schofield [EMAIL PROTECTED] wrote: BTW, it appears i did not commit the test last night or the fix today.
I just committed both to the branch. Sean On 4/12/06, Sean Schofield [EMAIL PROTECTED] wrote:  Ok so this is how things work outside of unit tests.I am committing
  a fix that I think should work for the unit test (and TCK) and still  leave the existing functionality the way it is (which is presumably  good b/c we've heard no complaints on this.)
   Sean   On 4/12/06, Dennis Byrne [EMAIL PROTECTED] wrote:   MyFaces looks for a parameter called jsf_sequence .Do a few post backs on any form page in the example app and you'll see this incremented.This is how the impl keeps track of which view to associate w/ each
 IF YOU KNOW ANYTHING MORE ON THIS, HELP. Dennis Byrne -Original Message-   From: Sean Schofield [mailto:
[EMAIL PROTECTED]]   Sent: Wednesday, April 12, 2006 11:58 AM   To: 'MyFaces Development'   Subject: Re: [IMPORTANT] Major blocker issue: MYFACES-1281
  Still waiting for some help on this issue.Come on MyFaces committers   lets get this one figured out.You don't need the TCK to fix this.   Just make the unit test work and help explain how it works (if it ever
   worked) in the standard non-unit test case.  Sean  On 4/11/06, Sean Schofield 
[EMAIL PROTECTED] wrote:There is an outstanding issue that is preventing us from passing theTCK.Without this we cannot release a JSF 1.1 certified release.We
could use everyone's help in tracking this down and resolving ASAP.We need to get on with the 1.1.2 release.   Sean
   ps. More frequent releases should help reduce the number of supriseTCK failures per release.Also more unit tests will be helpful here.

RE: Core 1.1.2 Branch - Incorrect Dependency?

2006-04-13 Thread Jeremy J. Grelle

Sean,

Thanks, Core looks good now.

Are we supposed to be testing the Tomahawk 1.1.2 branch as well, or is
the focus just on Shared and Core right now?  I ask because as it stands
right now in the branch, Tomahawk's core pom.xml is still pointing to
myfaces-shared-impl-2.0.0-SNAPSHOT.jar.

Jeremy

-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 12, 2006 8:03 PM
To: MyFaces Development
Subject: Re: Core 1.1.2 Branch - Incorrect Dependency?

Jeremy,

You're correct about the dependency.  I had changed it in the
dependency section but forgot about Manfred's shared refactoring
magic.  Good catch.  I'm checking in a fixed POM now.

Sean

On 4/12/06, Jeremy J. Grelle [EMAIL PROTECTED] wrote:



 Hello everyone.  I just started to try and do some testing of the
1.1.2
 release and noticed a possible problem when I cleared out my maven
repo so
 that I could do a clean build.  When building the core-impl package,
maven
 went and grabbed myfaces-shared-impl-2.0.1-SNAPSHOT.jar for
 the repackaging bit.  Shouldn't it be getting
myfaces-shared-impl-2.0.0.jar?



 Found the following bit in the pom.xml that is triggering this:



  plugin

 groupIdorg.codehaus.mojo/groupId

 artifactIddependency-maven-plugin/artifactId

 executions

   execution

 idunpack-shared-impl/id

 phaseprocess-classes/phase

 goalsgoalunpack/goal/goals

 configuration

   artifactItems

 artifactItem

groupIdorg.apache.myfaces.shared/groupId


 artifactIdmyfaces-shared-impl/artifactId

version2.0.1-SNAPSHOT/version

  /artifactItem

/artifactItems


 outputDirectory${project.build.directory}/classes/outputDirectory

 /configuration

   /execution

 /executions

   /plugin



 Thanks,

 Jeremy

Re: Puzzled about generated code

On 4/13/06, Manfred Geiler [EMAIL PROTECTED] wrote:
 In a few minutes I will checkin the reborn codegenerator - stay tuned.

Excellent!  We can start working on facelet and shale support now.

Re: Core 1.1.2 Branch - Incorrect Dependency?

On 4/13/06, Jeremy J. Grelle [EMAIL PROTECTED] wrote:
 Are we supposed to be testing the Tomahawk 1.1.2 branch as well, or is
 the focus just on Shared and Core right now?

Shared and Core right now.


 I ask because as it stands
 right now in the branch, Tomahawk's core pom.xml is still pointing to
 myfaces-shared-impl-2.0.0-SNAPSHOT.jar.

That seems wrong.   Tomahawk shouldn't have any shared_impl
dependencies right now.   Try changing it to shared-tomahawk.  
Sandbox still has a few core dependencies, but those are slowing being
removed.

Re: [IMPORTANT] Major blocker issue: MYFACES-1281

Hi!
 What about Mario's fix 2 hours ago? (see Jira)
:-D
I dont know which date jira shows, but I patched it for about half an
hour ago.

I already told Sean about it and he prepares a new TCK test cycle.

Ciao,
Mario

Re: Any status update on the Subversion repos?

2006-04-13 Thread Jonas Jacobi





Thanks Craig,

I really appreciate this

- Jonas

Craig McClanahan wrote:
Jonas Jacobi
wrote:
  
  Hi Craig,


It is now three weeks since the announcement of the new adffaces-xxx
mailing lists. I know you are busy, but do you have a status update on
the creation of the Subversion repository for these components?


Thanks

- Jonas

--
*Author*: Pro JSF and Ajax: Building Rich Internet Components
http://apress.com/book/bookDisplay.html?bID=10044

*Blog*: http://www.orablogs.com/jjacobi



  
When I looked yesterday, the request to create this subversion
repository was 23rd on the list of outstanding infrastructure issues
(yes, it takes a long time :-( sometimes). However, in response to
some pings from me on Monday, it at least got assigned to someone who
promised to look at it "this week." Same thing (but different
volunteer) for the new account setups. I'll try again.
  
  
Craig
  
  


-- 
Author: Pro JSF and
Ajax: Building Rich Internet Components
Blog: 
http://www.orablogs.com/jjacobi

Re: Any status update on the Subversion repos?


Jonas Jacobi wrote:

Hi Craig,

It is now three weeks since the announcement of the new adffaces-xxx 
mailing lists. I know you are busy, but do you have a status update on 
the creation of the Subversion repository for these components?


Thanks
- Jonas
--
*Author*: Pro JSF and Ajax: Building Rich Internet Components 
http://apress.com/book/bookDisplay.html?bID=10044

*Blog*: http://www.orablogs.com/jjacobi


When I looked yesterday, the request to create this subversion 
repository was 23rd on the list of outstanding infrastructure issues 
(yes, it takes a long time :-( sometimes).  However, in response to some 
pings from me on Monday, it at least got assigned to someone who 
promised to look at it this week.  Same thing (but different 
volunteer) for the new account setups.  I'll try again.


Craig

Re: Any status update on the Subversion repos?

On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components?
 Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044
 *Blog*: http://www.orablogs.com/jjacobiWhen I looked yesterday, the request to create this subversionrepository was 23rd on the list of outstanding infrastructure issues
(yes, it takes a long time :-( sometimes).However, in response to somepings from me on Monday, it at least got assigned to someone whopromised to look at it this week.Same thing (but different
volunteer) for the new account setups.I'll try again.Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files.
--Martin CooperCraig

[jira] Closed: (MYFACES-821) Usage of request attributes for caching

2006-04-13 Thread Stan Silvert (JIRA)

 [ http://issues.apache.org/jira/browse/MYFACES-821?page=all ]
 
Stan Silvert closed MYFACES-821:


Resolution: Won't Fix

This is a problem in LifeRay.  The latest version has a fix.

 Usage of request attributes for caching
 ---

  Key: MYFACES-821
  URL: http://issues.apache.org/jira/browse/MYFACES-821
  Project: MyFaces Core
 Type: Bug

 Versions: 1.1.0
  Environment: liferay 3.6.1
 Reporter: Michael Lipp
 Assignee: Stan Silvert


 JspStateManagerImpl (and maybe other classes) uses request attributes for 
 caching state. This causes a wrong view to be used if there is more than one 
 JSF-based portlet on a single page. MyFaces saves the serialized view of the 
 first portlet on the page as a request attribute. To avoid re-serialization, 
 MyFaces subsequently checks if there already is a request attribute with a 
 serialized view. As request attributes are not scoped to a single portlet 
 (the portlet specification does not require this), the serialized view of the 
 first portlet will be found and used by the second portlet.
 This usage of request attributes may also be the cause of MYFACES-549.
 As JSF, of course, does not need to know about the portlet environment, it 
 cannot be required that MyFaces saves such information per view, e.g. by 
 prepending the viewId to the key for the request attribute (although this 
 would solve the problem). IMHO any request attributes added during 
 lifecycle.render() should be removed after lifecycle() render by the portlet 
 bridge. (The same applies to request attributes added during 
 lifecycle.execute(), but these should also be re-added before 
 lifecycle.render().) I have implemented this in my portlet bridge as a 
 workaround.

-- 
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

Re: [IMPORTANT] Major blocker issue: MYFACES-1281

Yes Mario's checkin will hopefull fix this.  I'm preparing a new TCK
for testing as we speak.

Sean

On 4/13/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
 Hi!
  What about Mario's fix 2 hours ago? (see Jira)
 :-D
 I dont know which date jira shows, but I patched it for about half an
 hour ago.

 I already told Sean about it and he prepares a new TCK test cycle.

 Ciao,
 Mario

[jira] Created: (TOMAHAWK-254) inputCalendar in datatable - Conversion error occurred.

2006-04-13 Thread Todd Smith (JIRA)

inputCalendar in datatable - Conversion error occurred.  
-

 Key: TOMAHAWK-254
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-254
 Project: MyFaces Tomahawk
Type: Bug

  Components: Calendar  
Versions: 1.1.1
 Environment: WSAD 5.1.2 with Tomahawk
Reporter: Todd Smith


When we are using the inputCalendar inside a datatable and binding it to our 
dataBeans we get conversion errors when we try to save changes or even navigate 
to another page. Conversion error occurred.  

This happened for all fields that were either populated or null.

example code:

h:dataTable width=750 border=1 cellpadding=0 cellspacing=0 
value=#{rateTableBB.productsListModel} var=results 
headerClass=DataText2Bold  rowClasses=DataText2,DataText2GrayBG 
columnClasses=center footerClass=center
... 
h:column 
t:inputCalendar id=productEndDate styleClass=InputField10 
monthYearRowClass=yearMonthHeader weekRowClass=weekHeader  
renderPopupButtonAsImage=true popupDateFormat=MM/dd/
renderAsPopup=true 
currentDayCellClass=currentDayCell size=10 
value=#{results.capnProvAgrmtGUIBean.utilDateTrmntnDt} 
onchange=checkThisRow(this,'productEndDate','row') /
 /h:column 
/dataTable

I'm not exacly sure why this is happening.  We couldn't get the dates to bind 
at all even outside a datatable unless we used Java.util.Dates and we had to 
bind to a field directly in our backing bean ie. 
#{ourBackingBean.someUtilDate}.  Then we have to manually get/set our date 
field from our transfer object.

If we try to link to a dataBean by reference, the page won't bind the date and 
nothing will submit.  #{someTransferObject.ourDatabean.someUtilDate}. Thus our 
page is effectively hung.

Has anyone come across these issue and how to fix?  We want to bind by 
reference to the transfer object.  Do we need to add all our databeans and 
transfer objects into our faces.config?







 


-- 
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

Re: Core 1.1.2 Branch - Incorrect Dependency?

I believe this branch should be blown away entirely.  The 1.1.2 stuff
is on the trunk.  We created this branch a while ago to sort out the
tohawk/shared refactoring.  Now that everything has been merged down I
think this branch should be killed.

Any objections?

Sean

On 4/13/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 On 4/13/06, Jeremy J. Grelle [EMAIL PROTECTED] wrote:
  Are we supposed to be testing the Tomahawk 1.1.2 branch as well, or is
  the focus just on Shared and Core right now?

 Shared and Core right now.


  I ask because as it stands
  right now in the branch, Tomahawk's core pom.xml is still pointing to
  myfaces-shared-impl-2.0.0-SNAPSHOT.jar.

 That seems wrong.   Tomahawk shouldn't have any shared_impl
 dependencies right now.   Try changing it to shared-tomahawk.
 Sandbox still has a few core dependencies, but those are slowing being
 removed.

Re: Core 1.1.2 Branch - Incorrect Dependency?

Hi!
 Now that everything has been merged down I
 think this branch should be killed.

 Any objections?
   
My last patch is not merged down, shall I commit it there?

Ciao,
Mario

Re: Any status update on the Subversion repos?

On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote:
On 4/13/06, Craig McClanahan 
[EMAIL PROTECTED] wrote:
Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components?
 Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components 
http://apress.com/book/bookDisplay.html?bID=10044
 *Blog*: http://www.orablogs.com/jjacobiWhen I looked yesterday, the request to create this subversion
repository was 23rd on the list of outstanding infrastructure issues
(yes, it takes a long time :-( sometimes).However, in response to somepings from me on Monday, it at least got assigned to someone whopromised to look at it this week.Same thing (but different

volunteer) for the new account setups.I'll try again.Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files.
That would be awesome. Thanks Martin!! 
--Martin Cooper
Craig

Craig

[jira] Closed: (MYFACES-549) faces navigation rules not working for two portlets on portal page

2006-04-13 Thread Stan Silvert (JIRA)

 [ http://issues.apache.org/jira/browse/MYFACES-549?page=all ]
 
Stan Silvert closed MYFACES-549:


Resolution: Won't Fix

The latest version of LifeRay has a fix for this.

 faces navigation rules not working for two portlets on portal page
 --

  Key: MYFACES-549
  URL: http://issues.apache.org/jira/browse/MYFACES-549
  Project: MyFaces Core
 Type: Bug

   Components: General
 Versions: 1.1.1
  Environment: Linux 2.6.12, Java 1.5.0_04, Liferay Pro 3.6.1 (portla), 
 nightly build (20050909)
 Reporter: zeroconf
 Priority: Minor
  Attachments: cardemo.war.zip

 I'm trying to write some JSF portlets within one portlet application
 but encountered some problems concerning navigation rules when I
 put more than one JSF portlet per portal page.
 When I put just one portlet on my page everything concerning the
 navigation rules (with h:commandButton action=p1next value=go on
 / stuff) works fine and I get to the next view.
 But when I put a second faces portlet on the page navigation and invoking
 actions on backing beans in the second portlet just doesn't work at all.
 If I remove both portlets and put the second portlet on the page again (so 
 that
 I'm having just one portlet again) this portlet works fine as well. So I 
 assume
 that navigation settings in faces-config.xml must be correct. It has
 something to do
 with the arrangement of two faces portlets on the portal page so that
 the second one
 stops working as expected.
 I also tried to use distinct IDs for all ui-components and also 
 distinct from-output-values but that doesn't help
 Thanks
 zeroconf
 Attached are the important parts of my web.xml, faces-config.xml and 
 portlet.xml
 web.xml
 
 ?xml version=1.0?
 !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web
 Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd;
 web-app
display-namePROJECT_NAME/display-name
context-param
param-namecompany_id/param-name
param-valueliferay.com/param-value
/context-param
context-param
param-namejavax.faces.STATE_SAVING_METHOD/param-name
param-valueclient/param-value
/context-param
context-param
param-namejavax.faces.application.CONFIG_FILES/param-name
param-value/WEB-INF/faces-config.xml/param-value
/context-param
listener
 listener-classcom.liferay.portal.servlet.PortletContextListener/listener-class
/listener
listener
 listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
/listener
servlet
servlet-namePROJECT_NAME/servlet-name
 servlet-classcom.liferay.portal.servlet.PortletServlet/servlet-class
init-param
param-nameportlet-class/param-name
 param-valueorg.apache.myfaces.portlet.MyFacesGenericPortlet/param-value
/init-param
load-on-startup0/load-on-startup
/servlet
servlet
servlet-nameFacesServlet/servlet-name
servlet-classjavax.faces.webapp.FacesServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-namePROJECT_NAME/servlet-name
url-pattern/PROJECT_NAME/*/url-pattern
/servlet-mapping
taglib
taglib-urihttp://java.sun.com/portlet/taglib-uri
 taglib-location/WEB-INF/tld/liferay-portlet.tld/taglib-location
/taglib
 /web-app
 faces-config.xml:
 ==
 ?xml version=1.0?
 !DOCTYPE faces-config PUBLIC -//Sun Microsystems, Inc.//DTD
 JavaServer Faces Config 1.1//EN
 http://java.sun.com/dtd/web-facesconfig_1_1.dtd;
 faces-config xmlns=http://java.sun.com/JSF/Configuration;
factory
 faces-context-factoryorg.apache.myfaces.context.MyFacesContextFactoryImpl/faces-context-factory
/factory
!-- navigation for JSF portlet 1 --
navigation-rule
from-view-id/jsp/jsf1/index.jsp/from-view-id
navigation-case
from-outcomep1next/from-outcome
to-view-id/jsp/jsf1/n1.jsp/to-view-id
/navigation-case
/navigation-rule
navigation-rule
from-view-id/jsp/jsf1/n1.jsp/from-view-id
navigation-case
from-outcomep1back/from-outcome
to-view-id/jsp/jsf1/index.jsp/to-view-id
/navigation-case
/navigation-rule
!-- navigation for JSF portlet 2 --
navigation-rule
from-view-id/jsp/jsf2/index.jsp/from-view-id
navigation-case
from-outcomep2next/from-outcome

Re: Core 1.1.2 Branch - Incorrect Dependency?

Oh, you didnt mean shared, sorry, I'll stop computing for today ;-)

---
Mario
 Now that everything has been merged down I
 think this branch should be killed.

 Any objections?
   
 
 My last patch is not merged down, shall I commit it there?

 Ciao,
 Mario

Re: Core 1.1.2 Branch - Incorrect Dependency?

We should wait and merge down everything (on both branches) once the
release is finalized.  I guess we make an exception for the one
command link thing you fixed earlier where the branch fix is
incompatible with the trunk code.  Please remind me to do this though
when the time comes.

Sean

On 4/13/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
 Oh, you didnt mean shared, sorry, I'll stop computing for today ;-)

 ---
 Mario
  Now that everything has been merged down I
  think this branch should be killed.
 
  Any objections?
 
 
  My last patch is not merged down, shall I commit it there?
 
  Ciao,
  Mario

[jira] Updated: (TOBAGO-54) visual text decoration component

2006-04-13 Thread Volker Weber (JIRA)

 [ http://issues.apache.org/jira/browse/TOBAGO-54?page=all ]

Volker Weber updated TOBAGO-54:
---

Status: Open  (was: Patch Available)

 visual text decoration component
 

  Key: TOBAGO-54
  URL: http://issues.apache.org/jira/browse/TOBAGO-54
  Project: MyFaces Tobago
 Type: New Feature

 Versions: 1.0.7
 Reporter: Nazar Stasiv
  Fix For: 1.0.8


 I need to manage t:link component text decoration. I have sheet component 
 with items t:link. First column displays t:link elements with underlined 
 font, but the rest of columns should be links without underlining. Since it 
 is not possible to apply font styles to t:link directly I propose to 
 introduce new t:font component which will add bold,italic,underline 
 attributes to manage font display in a flexible way. This wont break concept 
 of view layer. What do you think ? 

-- 
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

[jira] Commented: (TOBAGO-54) visual text decoration component

2006-04-13 Thread Volker Weber (JIRA)

[ 
http://issues.apache.org/jira/browse/TOBAGO-54?page=comments#action_12374410 ] 

Volker Weber commented on TOBAGO-54:


There is already a 'markup' attribute at out tag [1], I think we should add 
this attribute also to the link tag and discuss which markup types we will have.
Currendly possible values are 'none', 'strong' and 'deleted', but they are not 
realy supported by the themes.

[1] http://myfaces.apache.org/tobago/tobago-core/tlddoc/tc/out.html

 visual text decoration component
 

  Key: TOBAGO-54
  URL: http://issues.apache.org/jira/browse/TOBAGO-54
  Project: MyFaces Tobago
 Type: New Feature

 Versions: 1.0.7
 Reporter: Nazar Stasiv
  Fix For: 1.0.8


 I need to manage t:link component text decoration. I have sheet component 
 with items t:link. First column displays t:link elements with underlined 
 font, but the rest of columns should be links without underlining. Since it 
 is not possible to apply font styles to t:link directly I propose to 
 introduce new t:font component which will add bold,italic,underline 
 attributes to manage font display in a flexible way. This wont break concept 
 of view layer. What do you think ? 

-- 
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

Re: Any status update on the Subversion repos?

2006-04-13 Thread Jonas Jacobi





That would be fantastic!

Thanks plenty,
Jonas

Martin Cooper wrote:

  
  On 4/13/06, Craig McClanahan [EMAIL PROTECTED]
wrote:
  Jonas
Jacobi wrote:
 Hi Craig,

 It is now three weeks since the announcement of the new
adffaces-xxx
 mailing lists. I know you are busy, but do you have a status
update on
 the creation of the Subversion repository for these components?


 Thanks
 - Jonas
 --
 *Author*: Pro JSF and Ajax: Building Rich Internet Components
 http://apress.com/book/bookDisplay.html?bID=10044

 *Blog*: http://www.orablogs.com/jjacobi


When I looked yesterday, the request to create this subversion
repository was 23rd on the list of outstanding infrastructure issues

(yes, it takes a long time :-( sometimes).However, in response to some
pings from me on Monday, it at least got assigned to someone who
promised to look at it "this week."Same thing (but different
volunteer) for the new account setups.I'll try again.
  
Unless there's more to it than I think there is, I should be able to
take care of the SVN repo this evening, if Garrett doesn't beat me to
it. I believe all that's involved is adding the directories in SVN and
updating the auth and mailer config files.
  
  
--
Martin Cooper

  
  
  Craig

  
  
  


-- 
Author: Pro JSF and
Ajax: Building Rich Internet Components
Blog: 
http://www.orablogs.com/jjacobi

[jira] Created: (TOMAHAWK-255) inputCalendar in a datatable can't submit with null values

2006-04-13 Thread Todd Smith (JIRA)

inputCalendar in a datatable can't submit with null values
--

 Key: TOMAHAWK-255
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-255
 Project: MyFaces Tomahawk
Type: Bug

  Components: Calendar  
Versions: 1.1.1
 Environment: WSAD 5.1.2 - Windows 2000 - ie6
Reporter: Todd Smith


When I have an inputCalendar field in a datatable, i get a Conversion error 
occurred message for each inputcalendar field in my datatable that has a null 
value when I try to submit anything on the page.

This sounds similar to the myfaces 233 bug for the inputDate problem in a 
datatable.

Is there a way to turn off the converter/validator for null values?  I also 
noticed the onchange events don't seem to be working when you select a date 
from the calendar.

I also set required=false, to try to allow nulls, but that didn't work either.

Thanks



-- 
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

Re: Any status update on the Subversion repos?

I believe this is done. Your repo is at:https://svn.apache.org/repos/asf/incubator/adffaces/Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do.
I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17.Commits should go to the right place.If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues.
--Martin CooperOn 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED]
 wrote:   Jonas Jacobi wrote:   Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx   mailing lists. I know you are busy, but do you have a status update on
   the creation of the Subversion repository for these components? Thanks   - Jonas   --   *Author*: Pro JSF and Ajax: Building Rich Internet Components
   http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi
  When I looked yesterday, the request to create this subversion  repository was 23rd on the list of outstanding infrastructure issues  (yes, it takes a long time :-( sometimes).However, in response to some
  pings from me on Monday, it at least got assigned to someone who  promised to look at it this week.Same thing (but different  volunteer) for the new account setups.I'll try again.
 Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating
 the auth and mailer config files.That would be awesome.Thanks Martin!!-- Martin Cooper Craig   Craig

Re: Any status update on the Subversion repos?

On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote:
I believe this is done. Your repo is at:https://svn.apache.org/repos/asf/incubator/adffaces/
Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do.
I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17.Commits should go to the right place.If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues.
Works for me (complete with email to the commits list) ... thanks Martin!I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right? I'm on the Incubator PMC, so karma for that shouldn't be a problem.
Craig--
Martin CooperOn 4/13/06, Craig McClanahan 
[EMAIL PROTECTED] wrote:

On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan 
[EMAIL PROTECTED]
 wrote:   Jonas Jacobi wrote:   Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx   mailing lists. I know you are busy, but do you have a status update on
   the creation of the Subversion repository for these components? Thanks   - Jonas   --   *Author*: Pro JSF and Ajax: Building Rich Internet Components
   http://apress.com/book/bookDisplay.html?bID=10044*Blog*: 
http://www.orablogs.com/jjacobi
  When I looked yesterday, the request to create this subversion  repository was 23rd on the list of outstanding infrastructure issues  (yes, it takes a long time :-( sometimes).However, in response to some
  pings from me on Monday, it at least got assigned to someone who  promised to look at it this week.Same thing (but different  volunteer) for the new account setups.I'll try again.
 Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating
 the auth and mailer config files.That would be awesome.Thanks Martin!!-- Martin Cooper Craig   Craig

Re: Any status update on the Subversion repos?

On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 4/13/06, Martin Cooper [EMAIL PROTECTED]
 wrote:

I believe this is done. Your repo is at:https://svn.apache.org/repos/asf/incubator/adffaces/
Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do.
I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17.Commits should go to the right place.If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues.
Works for me (complete with email to the commits list) ... thanks Martin!No problem. Happy to help. 
I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right?
Right. 
 I'm on the Incubator PMC, so karma for that shouldn't be a problem.
Actually, only PMC chairs have explicit rights for that, but I think you'll be OK because you're an ASF member.--Martin Cooper
Craig
--
Martin CooperOn 4/13/06, Craig McClanahan 
[EMAIL PROTECTED] wrote:


On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan 
[EMAIL PROTECTED]
 wrote:   Jonas Jacobi wrote:   Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx   mailing lists. I know you are busy, but do you have a status update on
   the creation of the Subversion repository for these components? Thanks   - Jonas   --   *Author*: Pro JSF and Ajax: Building Rich Internet Components
   http://apress.com/book/bookDisplay.html?bID=10044*Blog*: 
http://www.orablogs.com/jjacobi
  When I looked yesterday, the request to create this subversion  repository was 23rd on the list of outstanding infrastructure issues  (yes, it takes a long time :-( sometimes).However, in response to some
  pings from me on Monday, it at least got assigned to someone who  promised to look at it this week.Same thing (but different  volunteer) for the new account setups.I'll try again.
 Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating
 the auth and mailer config files.That would be awesome.Thanks Martin!!-- Martin Cooper Craig   Craig

Re: Any status update on the Subversion repos?

On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote:
On 4/13/06, Craig McClanahan
[EMAIL PROTECTED] wrote:

On 4/13/06, Martin Cooper [EMAIL PROTECTED]
wrote:

I believe this is done. Your repo is at:https://svn.apache.org/repos/asf/incubator/adffaces/
Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do.
I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17.Commits should go to the right place.If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues.
Works for me (complete with email to the commits list) ... thanks Martin!No problem. Happy to help.

I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right?
Right.

I'm on the Incubator PMC, so karma for that shouldn't be a problem.
Actually, only PMC chairs have explicit rights for that, but I think you'll be OK because you're an ASF member.
It's not letting me right now ... i'll go ahead and request karma on the infra list.
--Martin CooperCraig

Craig
--
Martin CooperOn 4/13/06, Craig McClanahan
[EMAIL PROTECTED] wrote:

On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan
[EMAIL PROTECTED]
wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on
the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components
http://apress.com/book/bookDisplay.html?bID=10044*Blog*:
http://www.orablogs.com/jjacobi
When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to some
pings from me on Monday, it at least got assigned to someone who promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again.
Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating
the auth and mailer config files.That would be awesome.Thanks Martin!!-- Martin Cooper Craig Craig

Re: Any status update on the Subversion repos?

Excellent, thanks!  Once I get an apache account,
karma for the SVN, and a bit of free time, I can
check this puppy in and we can started for real!

-- Adam


On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
 On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote:
 
  I believe this is done. Your repo is at:
 
  https://svn.apache.org/repos/asf/incubator/adffaces/
 
  Note that I have not created the standard trunk / tags / branches
  directories in there, since incubator podlings appear to be doing things
  differently - some have them, some don't - so I figured I'd let you decide
  what you want to do.
 
  I've given karma to craigmcc, matzew, mmarinschek and baranda, per
  INCUBATOR-17.
 
  Commits should go to the right place.
 
  If someone could verify for me that it's all working, I'll go ahead and
  close out the JIRA issues.
 

 Works for me (complete with email to the commits list) ... thanks Martin!

 I assume that granting karma to other authorized committers is just a matter
 of editing the infrastructure subversion/asf-authorization file, right?  I'm
 on the Incubator PMC, so karma for that shouldn't be a problem.

 Craig


 --
  Martin Cooper
 
 
 
  On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
  
   On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote:
   
   
   
On 4/13/06, Craig McClanahan [EMAIL PROTECTED]  wrote:

 Jonas Jacobi wrote:
  Hi Craig,
 
  It is now three weeks since the announcement of the new
   adffaces-xxx
  mailing lists. I know you are busy, but do you have a status
   update on
  the creation of the Subversion repository for these components?
 
  Thanks
  - Jonas
  --
  *Author*: Pro JSF and Ajax: Building Rich Internet Components
  http://apress.com/book/bookDisplay.html?bID=10044 
  *Blog*: http://www.orablogs.com/jjacobi
 
 
 When I looked yesterday, the request to create this subversion
 repository was 23rd on the list of outstanding infrastructure issues
 (yes, it takes a long time :-( sometimes).  However, in response to
   some
 pings from me on Monday, it at least got assigned to someone who
 promised to look at it this week.  Same thing (but different
 volunteer) for the new account setups.  I'll try again.
   
   
Unless there's more to it than I think there is, I should be able to
   take
care of the SVN repo this evening, if Garrett doesn't beat me to it. I
believe all that's involved is adding the directories in SVN and
   updating
the auth and mailer config files.
   
  
   That would be awesome.  Thanks Martin!!
  
   --
Martin Cooper
   
   
Craig


Craig

Re: Any status update on the Subversion repos?

Scratch item #1 - just got the e-mail, [EMAIL PROTECTED]
now exists. ;)  Who can grant me karma for
http://svn.apache.org/repos/asf/incubator/adffaces/?

-- Adam


On 4/13/06, Adam Winer [EMAIL PROTECTED] wrote:
 Excellent, thanks!  Once I get an apache account,
 karma for the SVN, and a bit of free time, I can
 check this puppy in and we can started for real!

 -- Adam


 On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
  On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote:
  
   I believe this is done. Your repo is at:
  
   https://svn.apache.org/repos/asf/incubator/adffaces/
  
   Note that I have not created the standard trunk / tags / branches
   directories in there, since incubator podlings appear to be doing things
   differently - some have them, some don't - so I figured I'd let you decide
   what you want to do.
  
   I've given karma to craigmcc, matzew, mmarinschek and baranda, per
   INCUBATOR-17.
  
   Commits should go to the right place.
  
   If someone could verify for me that it's all working, I'll go ahead and
   close out the JIRA issues.
  
 
  Works for me (complete with email to the commits list) ... thanks Martin!
 
  I assume that granting karma to other authorized committers is just a matter
  of editing the infrastructure subversion/asf-authorization file, right?  I'm
  on the Incubator PMC, so karma for that shouldn't be a problem.
 
  Craig
 
 
  --
   Martin Cooper
  
  
  
   On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
   
On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote:



 On 4/13/06, Craig McClanahan [EMAIL PROTECTED]  wrote:
 
  Jonas Jacobi wrote:
   Hi Craig,
  
   It is now three weeks since the announcement of the new
adffaces-xxx
   mailing lists. I know you are busy, but do you have a status
update on
   the creation of the Subversion repository for these components?
  
   Thanks
   - Jonas
   --
   *Author*: Pro JSF and Ajax: Building Rich Internet Components
   http://apress.com/book/bookDisplay.html?bID=10044 
   *Blog*: http://www.orablogs.com/jjacobi
  
  
  When I looked yesterday, the request to create this subversion
  repository was 23rd on the list of outstanding infrastructure issues
  (yes, it takes a long time :-( sometimes).  However, in response to
some
  pings from me on Monday, it at least got assigned to someone who
  promised to look at it this week.  Same thing (but different
  volunteer) for the new account setups.  I'll try again.


 Unless there's more to it than I think there is, I should be able to
take
 care of the SVN repo this evening, if Garrett doesn't beat me to it. I
 believe all that's involved is adding the directories in SVN and
updating
 the auth and mailer config files.

   
That would be awesome.  Thanks Martin!!
   
--
 Martin Cooper


 Craig
 
 
 Craig

Re: Any status update on the Subversion repos?

On 4/13/06, Adam Winer [EMAIL PROTECTED] wrote:
Scratch item #1 - just got the e-mail, [EMAIL PROTECTED]now exists. ;)Who can grant me karma forhttp://svn.apache.org/repos/asf/incubator/adffaces/
?Scratch #2 - you now have karma. Now all you need is free time. ;-)John Fallows also now has karma. FYI, we still don't have ICLAs from Jonas Jacobi or Omar Tazi.--Martin Cooper
-- AdamOn 4/13/06, Adam Winer
[EMAIL PROTECTED] wrote: Excellent, thanks!Once I get an apache account, karma for the SVN, and a bit of free time, I can check this puppy in and we can started for real! -- Adam
On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED]
wrote: I believe this is done. Your repo is at: https://svn.apache.org/repos/asf/incubator/adffaces/
Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide
what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17. Commits should go to the right place.
If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin!
I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right?I'm on the Incubator PMC, so karma for that shouldn't be a problem.
Craig-- Martin Cooper On 4/13/06, Craig McClanahan
[EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote:
On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote:
Hi Craig, It is now three weeks since the announcement of the newadffaces-xxx mailing lists. I know you are busy, but do you have a status
update on the creation of the Subversion repository for these components? Thanks
- Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components
http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi
When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues
(yes, it takes a long time :-( sometimes).However, in response tosome pings from me on Monday, it at least got assigned to someone who
promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again.
Unless there's more to it than I think there is, I should be able totake care of the SVN repo this evening, if Garrett doesn't beat me to it. I
believe all that's involved is adding the directories in SVN andupdating the auth and mailer config files.
That would be awesome.Thanks Martin!! -- Martin Cooper Craig
Craig

Re: Any status update on the Subversion repos?

On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote:
On 4/13/06, Adam Winer
[EMAIL PROTECTED] wrote:

Scratch item #1 - just got the e-mail, [EMAIL PROTECTED]now exists. ;)Who can grant me karma for
http://svn.apache.org/repos/asf/incubator/adffaces/
?Scratch #2 - you now have karma. Now all you need is free time. ;-)Plus one more detail :-). We need to decide about the organization of the incubator repository. I'll post a separate thread on that in just a minute.
John Fallows also now has karma. FYI, we still don't have ICLAs from Jonas Jacobi or Omar Tazi.
--Martin Cooper
Craig
-- AdamOn 4/13/06, Adam Winer

[EMAIL PROTECTED] wrote: Excellent, thanks!Once I get an apache account, karma for the SVN, and a bit of free time, I can check this puppy in and we can started for real! -- Adam
On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper
[EMAIL PROTECTED]
wrote: I believe this is done. Your repo is at:
https://svn.apache.org/repos/asf/incubator/adffaces/
Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide
what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17. Commits should go to the right place.
If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin!
I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right?I'm on the Incubator PMC, so karma for that shouldn't be a problem.
Craig-- Martin Cooper On 4/13/06, Craig McClanahan

[EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED]
wrote:
On 4/13/06, Craig McClanahan [EMAIL PROTECTED]
wrote: Jonas Jacobi wrote:
Hi Craig, It is now three weeks since the announcement of the newadffaces-xxx
mailing lists. I know you are busy, but do you have a status
update on the creation of the Subversion repository for these components? Thanks

- Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components
http://apress.com/book/bookDisplay.html?bID=10044*Blog*:
http://www.orablogs.com/jjacobi
When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues
(yes, it takes a long time :-( sometimes).However, in response tosome pings from me on Monday, it at least got assigned to someone who
promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again.
Unless there's more to it than I think there is, I should be able totake care of the SVN repo this evening, if Garrett doesn't beat me to it. I
believe all that's involved is adding the directories in SVN andupdating the auth and mailer config files.
That would be awesome.Thanks Martin!! -- Martin Cooper Craig
Craig

Re: Any status update on the Subversion repos?