HTMLCalendarRendrer Bug Solution Patch

[Hazem Saleh]

Hi Guys;
If anyone has some free time; Would (s)he please apply the
HTMLCalendarRendrer defect solution for Arabic locale.
https://issues.apache.org/jira/browse/TOMAHAWK-1147
Thanks all very much.

Hazem Ahmed Saleh
http://www.jroller.com/HazemBlog

Extended Dojo Library

[Hazem Saleh]

Hi Guys;
Just a small question;
Can we use extended Dojo library (Dojox) for developing
components in sandbox project ?
Thanks very much.

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Extended Dojo Library

[Hazem Saleh]

Hello Gerald;
Actually Dojo 1.0.0 has many nice stuff :).
I will follow your idea; making local development till Werner makes the update.
Thanks very much.

On Nov 16, 2007 3:04 PM, Gerald Müllan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> tomahawk actually works with the pretty outdated dojo 0.4.1 version.
>
> As I know, dojox was introduced afterwards.
>
> Werner will do the update to 1.0 the next weeks, so I think you have
> to wait with sandbox work until the migration has been finished.
>
> But this doesn`t prevent you from developing with 1.0 locally; We can
> push new stuff into sandbox afterwards.
>
> cheers,
>
> Gerald
>
>
> On Nov 16, 2007 1:48 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > Hi Guys;
> > Just a small question;
> > Can we use extended Dojo library (Dojox) for developing
> > components in sandbox project ?
> > Thanks very much.
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
> >
>
>
>
> --
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Arabizing the Tomahawk Calendar

[Hazem Saleh]

Hi all,
Please apply this patch if you have sometime.
Here is the JIRA issue url :
https://issues.apache.org/jira/browse/TOMAHAWK-1155
This patch contains the arabization support for the Tomahawk Calendar
Thanks all very much.
I really appreciate your efforts.

--
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Reminder: i18n Tomahawk Calendar patch

[Hazem Saleh]

Hi all,
Please apply this patch if you have sometime.
Here is the JIRA issue url :
https://issues.apache.org/jira/browse/TOMAHAWK-1155
This patch contains the arabization support for the Tomahawk Calendar
Thanks all very much.
I really appreciate your efforts.

--
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

MyFaces Core Components Arabization Patch

[Hazem Saleh]

Hi all,
Please apply this patch if you have sometime.
Here is the JIRA issue url :
https://issues.apache.org/jira/browse/MYFACES-1784
This patch contains the arabization support for the MyFaces core components.
Thanks all very much.
I really appreciate your efforts.

--
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: MyFaces Core Components Arabization Patch

[Hazem Saleh]

Hi Matzew;
It is for MyFaces 1.1.6 core.


On Dec 4, 2007 7:40 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Hi,
>
> thanks for your efforts.
> Is that a fix for the 1.2x CORE ?
>
> -M
>
>
> On Dec 4, 2007 1:14 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > Hi all,
> > Please apply this patch if you have sometime.
> > Here is the JIRA issue url :
> > https://issues.apache.org/jira/browse/MYFACES-1784
> > This patch contains the arabization support for the MyFaces core components.
> > Thanks all very much.
> > I really appreciate your efforts.
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
> >
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: MyFaces Core Components Arabization Patch

[Hazem Saleh]

Hi Matzew;
I have finally done all the Arabic translation and integrated at
MyFaces 1.2.1 :).
Here is the patch :-
https://issues.apache.org/jira/browse/MYFACES-1785
Thanks very much for your efforts!

On Dec 4, 2007 11:26 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> Hi Matzew;
> It is for MyFaces 1.1.6 core.
>
>
>
> On Dec 4, 2007 7:40 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > thanks for your efforts.
> > Is that a fix for the 1.2x CORE ?
> >
> > -M
> >
> >
> > On Dec 4, 2007 1:14 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > > Hi all,
> > > Please apply this patch if you have sometime.
> > > Here is the JIRA issue url :
> > > https://issues.apache.org/jira/browse/MYFACES-1784
> > > This patch contains the arabization support for the MyFaces core 
> > > components.
> > > Thanks all very much.
> > > I really appreciate your efforts.
> > >
> > > --
> > > Hazem Ahmed Saleh Ahmed
> > > http://www.jroller.com/page/HazemBlog
> > >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > mail: matzew-at-apache-dot-org
> >
>
>
>
> --
>
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/HazemBlog

Re: myFaces vs MyFaces ... what do you think ?

[Hazem Saleh]

+1 for M  :).

On Dec 9, 2007 1:34 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> I'd always call it:
> Apache MyFaces Tomahawk
> Apache MyFaces Tobago
> Apache MyFaces Trinidad
> Apache MyFaces Blah
> ...
>
>
> On Dec 9, 2007 3:25 AM, Adonis Raduca <[EMAIL PROTECTED]> wrote:
> >
> >
> > I think that is important to have a consistent naming strategy for all
> > myFaces (MyFaces) projects. For example I thought to one similar with the
> > Java naming convention for the instance variables.
> > Something like:
> > myFaces
> > tobago
> > tomahawk
> > …
> >
> >
> > I think that once the naming strategy will be in place must be respected
> > everywhere (logos, text stuff, etc.)
> >
> > Adonis
> >
> >
> >
> > On 12/8/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > > Eh, I think that is total different beast.
> > > We all work here as individuals and it is ok to "misspell" names...
> > >
> > > But... starting to misspell the own project, is ... yes, confusing.
> > >
> > > -M
> > >
> > > On Dec 8, 2007 8:47 PM, Bruno Aranda < [EMAIL PROTECTED]> wrote:
> > > > I am not so sure if it is the same writing the official name of the
> > > > project (Apache MyFaces) that what we find in the (myFaceS). For
> > > > instance, most of the time we write in this list "Oracle" instead of
> > > > "ORACLE" (logo). I guess we should just choose which one is more
> > > > appealing to us, so just vote and let the outcome be our choice :)
> > > >
> > > > My 2 cents,
> > > >
> > > > Bruno
> > > >
> > > >
> > > > On 08/12/2007, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> > > > > On 12/8/07, Matthias Wessendorf < [EMAIL PROTECTED]> wrote:
> > > > > > I too, and I think it is confusing, when we start to write it
> > wrong..
> > > > > >
> > > > > 
> > > > >
> > > > > Indeed, its important to get the name right (case et al), especially
> > > > > in the logo :-)
> > > > >
> > > > > -Rahul
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > mail: matzew-at-apache-dot-org
> > >
> >
> >
>
>
>
> --
>
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

The MyFaces Sandbox CAPTCHA component is released :)

[Hazem Saleh]

Hi Guys,

Iam pleased to tell you that I finally finished developing the CAPTCHA
component.

*We can now have a CAPTCHA by just writing:*

This would generates a captcha with a random text image then set the
generated text
in the session attribute "mySessionKey".

I hope that you all like the new Apache MyFaces sandbox CAPTCHA component
:).
Here is the patch link:
https://issues.apache.org/jira/browse/TOMAHAWK-1207

Later, I will include the component documentation patch.
BTW, I would like to thank Zubin wadia, Martin Marinschek, Thomas speigl for
encouraging
me developing this component.

I really like all the Apache MyFaces community.
Thanks to all of you.
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/HazemBlog

Re: The MyFaces Sandbox CAPTCHA component is released :)

[Hazem Saleh]

Guys,
I removed all the references to the Sun specific JDK classes.
I replaced them with Apache AWT BATIK :).
Thanks all very much :).

On Sun, Mar 2, 2008 at 8:11 PM, Manfred Geiler <[EMAIL PROTECTED]>
wrote:

> cool component - thanks!
>
> --Manfred
>
> On Fri, Feb 29, 2008 at 6:15 PM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
> > Hi Guys,
> >
> > Iam pleased to tell you that I finally finished developing the CAPTCHA
> > component.
> >
> > We can now have a CAPTCHA by just writing:
> > 
> >  This would generates a captcha with a random text image then set the
> > generated text
> > in the session attribute "mySessionKey".
> >
> > I hope that you all like the new Apache MyFaces sandbox CAPTCHA
> component
> > :).
> >  Here is the patch link:
> > https://issues.apache.org/jira/browse/TOMAHAWK-1207
> >
> > Later, I will include the component documentation patch.
> > BTW, I would like to thank Zubin wadia, Martin Marinschek, Thomas speigl
> for
> > encouraging
> >  me developing this component.
> >
> > I really like all the Apache MyFaces community.
> > Thanks to all of you.
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/HazemBlog
>
>
>
> --
> http://www.irian.at
> Your JSF powerhouse - JSF Consulting,
> Development and Courses in English and
> German
>
> Professional Support for Apache MyFaces
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

CAPTCHA component - Enhancement #1

[Hazem Saleh]

Hi all,
   Please apply this patch if you have sometime.

   Here is the JIRA issue url :
   https://issues.apache.org/jira/browse/TOMAHAWK-1212

   Thanks all very much.
   I really appreciate your efforts.
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

CAPTCHA component - Enhancement #2 - Removing the dedicated servlet

[Hazem Saleh]

Hi all,
   Please apply this patch if you have sometime.

   Here is the JIRA issue url :
   https://issues.apache.org/jira/browse/TOMAHAWK-1216

   This patch removes the dedicated servlet from the CAPTCHA component,
   It integrates the component with the great Extension filter Resource
loader :).

   Thanks all very much.
   I really appreciate your efforts and I really like this project :).

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

New Tomahawk sandbox component - PDF Exporter :)

[Hazem Saleh]

Hi guys,
Iam planning to start a new Tomahawk sandbox component that generates PDF
files.
I just want to ask whether I can use (iText) java library or not.
After checking its license, I found it LGPL and MPL.
Here is the url :
http://www.lowagie.com/iText/download.html
Please tell me if I can use it or not.
Thanks all.

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: New Tomahawk sandbox component - PDF Exporter :)

[Hazem Saleh]

Thank you :).

On Wed, Apr 2, 2008 at 10:12 PM, Cagatay Civici <[EMAIL PROTECTED]>
wrote:

> If it's LPGL, nope:)
>
>
> On Wed, Apr 2, 2008 at 10:57 PM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
>
> > Hi guys,
> > Iam planning to start a new Tomahawk sandbox component that generates
> > PDF files.
> > I just want to ask whether I can use (iText) java library or not.
> > After checking its license, I found it LGPL and MPL.
> > Here is the url :
> > http://www.lowagie.com/iText/download.html
> > Please tell me if I can use it or not.
> > Thanks all.
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

The pdfExport component released ;)

[Hazem Saleh]

Hi guys,
Iam pleased to tell you that the (PDFExport) component is finished.
It works like the (excelExport) component.

for example)




Here is the patch url :
https://issues.apache.org/jira/browse/TOMAHAWK-1229

Thanks all :).
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: The pdfExport component released ;)

[Hazem Saleh]

Hi mates,

I was about to suggest merging these two components (excel, pdf) export into
one component.

While I was developing the component, I intended to cope with the same
structure of the excelExport so that we can integrate them easily and
finally have a unified one component called (Exporter) for example :D which
works on standard HTML tables.

Here is an example in my mind)




I can work on making these two components in one component soon if you all
don't mind.

Thanks mates.


On Sat, Apr 5, 2008 at 11:55 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:

> Hi
>
> On Sat, Apr 5, 2008 at 10:58 AM, Cagatay Civici
> <[EMAIL PROTECTED]> wrote:
> > Great!
> >
> > Does it work with client side state saving?
> >
> > Also since this is similar to excelexport which uses a phaselistener, we
> > should combine these into a ExporterPhaseListener to remove duplication.
>
> true. I thought the same. Internally we have a
> "exportCollectionActionListener" that has a type
> attribute to specify the desired *output*. We currently only support
> "excelHTML", but in order to
> support PDF, I would expect we also allow the type="pdf" case.
>
> So, a combination is desired.
>
> I have a question for you, is the excel independent from Tomahawk,
> like the PDF is ?
>
> But... anyway, this is sandbox and it is a great component. I am happy
> about it.
>
> Sandbox means not final / stable, so there might be room for
> improvements / changes.
>
> Thanks Hazem!
>
> -Matthias
>
> >
> >
> >
> >  On Sat, Apr 5, 2008 at 11:43 AM, Volker Weber <[EMAIL PROTECTED]>
> wrote:
> > > Hi,
> > >
> > > thanks Hazem,
> > >
> > > did this depends on the tomahawk datatable? Or does it also works with
> > > the standard h:datatable. If so i would prefer to see this in
> > > commons-(components ?) instead of in tomahawk.
> > >
> > >
> > > Regards,
> > >Volker
> > >
> > >
> > >
> > > 2008/4/5, Hazem Saleh <[EMAIL PROTECTED]>:
> > >
> > >
> > >
> > > > Hi guys,
> > > > Iam pleased to tell you that the (PDFExport) component is finished.
> > > > It works like the (excelExport) component.
> > > >
> > > > for example)
> > > > 
> > > > 
> > > >  
> > > >
> > > > Here is the patch url :
> > > > https://issues.apache.org/jira/browse/TOMAHAWK-1229
> > > >
> > > > Thanks all :).
> > > > --
> > > > Hazem Ahmed Saleh Ahmed
> > > >  http://www.jroller.com/page/HazemBlog
> > >
> > >
> > > --
> > > inexso - information exchange solutions GmbH
> > > Bismarckstraße 13  | 26122 Oldenburg
> > > Tel.: +49 441 4082 356 |
> > > FAX:  +49 441 4082 355 | www.inexso.de
> > >
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: pdfExport Dependencies

[Hazem Saleh]

Hi Grant,
I asked the guys about its license and they told me it is OK.

On Sat, Apr 5, 2008 at 6:59 PM, Grant Smith <[EMAIL PROTECTED]> wrote:

> https://issues.apache.org/jira/browse/TOMAHAWK-1229
>
> Incorporates a dependency  in iText, which is cover by a MPL and LGPL.
> Does this mean we cannot include it in the Tomahawk sandbox ?
>
> --
> Grant Smith
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: pdfExport Dependencies

[Hazem Saleh]

Hi Guys,
I have a small question.
What are the licenses that we can use during our development in MyFaces
projects ?

On Sat, Apr 5, 2008 at 7:04 PM, Grant Smith <[EMAIL PROTECTED]> wrote:

> OK.. If there are no objections, I will commit.
>
>
> On Sat, Apr 5, 2008 at 10:01 AM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
>
> > Hi Grant,
> > I asked the guys about its license and they told me it is OK.
> >
> >
> > On Sat, Apr 5, 2008 at 6:59 PM, Grant Smith <[EMAIL PROTECTED]>
> > wrote:
> >
> > > https://issues.apache.org/jira/browse/TOMAHAWK-1229
> > >
> > > Incorporates a dependency  in iText, which is cover by a MPL and LGPL.
> > > Does this mean we cannot include it in the Tomahawk sandbox ?
> > >
> > > --
> > > Grant Smith
> > >
> >
> >
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>
>
> --
> Grant Smith
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: pdfExport Dependencies

[Hazem Saleh]

Thanks Matzew :).

On Sat, Apr 5, 2008 at 7:19 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:

> On Sat, Apr 5, 2008 at 7:09 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > Hi Guys,
> > I have a small question.
> > What are the licenses that we can use during our development in MyFaces
> > projects ?
>
> http://people.apache.org/~rubys/3party.html<http://people.apache.org/%7Erubys/3party.html>
>
> mozilla is in cat B.
>
> -M
>
> >
> >
> >
> > On Sat, Apr 5, 2008 at 7:04 PM, Grant Smith <[EMAIL PROTECTED]>
> wrote:
> >
> > > OK.. If there are no objections, I will commit.
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Apr 5, 2008 at 10:01 AM, Hazem Saleh <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > Hi Grant,
> > > > I asked the guys about its license and they told me it is OK.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Apr 5, 2008 at 6:59 PM, Grant Smith <[EMAIL PROTECTED]>
> > wrote:
> > > >
> > > > > https://issues.apache.org/jira/browse/TOMAHAWK-1229
> > > > >
> > > > > Incorporates a dependency  in iText, which is cover by a MPL and
> LGPL.
> > Does this mean we cannot include it in the Tomahawk sandbox ?
> > > > >
> > > > > --
> > > > > Grant Smith
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Hazem Ahmed Saleh Ahmed
> > > > http://www.jroller.com/page/HazemBlog
> > >
> > >
> > >
> > > --
> > > Grant Smith
> > >
> >
> >
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: The pdfExport component released ;)

[Hazem Saleh]

Hi Alexander,
I will do these changes as soon as I complete the excel and pdf export
integration.
Your suggestions are really nice!
Thank you!

On Mon, Apr 7, 2008 at 9:24 AM, Jesse Alexander (KSFH 323) <
[EMAIL PROTECTED]> wrote:

>  Hi
>
> From the sample code it seems that your component will just put the
> content of one table
> into the PDF.
>
> For the PDF-export it would make sense to also allow
> - multiple tables
> - forms
> - even complete views
> to be exportable. Would this require a big refactoring to be possible?
>
> regards
> Alexander
>
>  --
> *From:* Hazem Saleh [mailto:[EMAIL PROTECTED]
> *Sent:* Saturday, April 05, 2008 3:23 AM
> *To:* MyFaces Development
> *Subject:* The pdfExport component released ;)
>
> Hi guys,
> Iam pleased to tell you that the (PDFExport) component is finished.
> It works like the (excelExport) component.
>
> for example)
> 
> 
> 
>
> Here is the patch url :
> https://issues.apache.org/jira/browse/TOMAHAWK-1229
>
> Thanks all :).
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [proposal] jsf validation with annotations

[Hazem Saleh]

Hi All...

  There is already an ongoing activity to implement JSR#303 -
http://www.jcp.org/en/jsr/detail?id=303 - and we started it as an Apache
Commons Sandbox project. Following links for discussion threads and the svn
repo of the new project:

http://thread.gmane.org/gmane.comp.jakarta.commons.devel/102655

http://thread.gmane.org/gmane.comp.jakarta.commons.devel/102683

http://svn.apache.org/repos/asf/commons/sandbox/validator2/

IMHO this will be a good base for more specific validation requirements,
like JSF or EJB specific validations.


On Sat, Apr 5, 2008 at 2:02 PM, Gerhard Petracek <[EMAIL PROTECTED]>
wrote:

> hello cagatay,
>
> i see your point. however, i don't agree. to keep it short:
> i don't like the idea to restrict sev-en to orchestra.
>
> don't get me wrong - orchestra is really great!
> however, it isn't alone out there.
> (e.g. spring web flow and much more)
>
> if sev-en is a goody or not is in the eye of the beholder.
> i would say e.g.: the possible jpa support is a goody of sev-en.
> (the core of sev-en doesn't depend on jpa or something else. the core
> depends only on the jsf api and at the moment on commons-logging ;))
>
> regards,
> gerhard
>
>
>
> 2008/4/4, Cagatay Civici <[EMAIL PROTECTED]>:
>
> > Hi,
> >
> > I think Orchestra is kinda out of it's original scope, Mario and Simon
> > couldn't resist and add many cool useful features like viewController,
> > dynaForm and more that are not related to conversations and persistence.
> >
> > Orchestra is becoming our alternative to seam, sev-en is a goodie right?
> > So rather than a seperate project, I've no problem if it gets merged in
> > Orchestra, just my 2 cents, it's up to further discussion.
> >
> > Cagatay
> >
> > On Fri, Apr 4, 2008 at 9:57 PM, Kito D. Mann <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > > *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED]
> > > *Sent:* Friday, April 04, 2008 2:47 PM
> > > *To:* MyFaces Development; [EMAIL PROTECTED]
> > > *Subject:* Re: [proposal] jsf validation with annotations
> > >
> > >
> > >
> > > hello kito,
> > >
> > > you can put every extension into a "commons" module.
> > >
> > > I see what you're saying. I suppose the main issue is the size of the
> > > module, and the number of perceived users.
> > >
> > > To be honest, I think Tomahawk is a better place for it, since
> > > Tomahawk contains a lot of stuff that belongs in the JSF core, like some
> > > basic validators.
> > >
> > > orchestra is about conversations and persistence
> > > and
> > > sev-en is about validation (simple and cross-component validation)
> > > at the moment i'm not aware of the difference.
> > >
> > > it might be ok to put specific sev-en annotation modules into the
> > > commons module (as i said - they are independent of the sev-en core).
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >  2008/4/4, Kito D. Mann <[EMAIL PROTECTED]>:
> > >
> > > Gerhard,
> > >
> > >
> > >
> > > Actually, it's different. Commons is a collection of useful utilities
> > > and features. Think of it in terms of the Apache Commons. Orchestra is 
> > > about
> > > conversations and persistence contexts.
> > >
> > >
> > >
> > > ~~~
> > > Kito D. Mann - Author, JavaServer Faces in Action
> > > http://www.virtua.com - JSF/Java EE consulting, training, and
> > > mentoring
> > > http://www.JSFCentral.com  - JavaServer
> > > Faces FAQ, news, and info
> > > phone: +1 203-653-2989
> > > fax: +1 203-653-2988
> > >
> > >
> > >
> > > *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED]
> > > *Sent:* Friday, April 04, 2008 12:56 PM
> > > *To:* MyFaces Development
> > > *Subject:* Re: [proposal] jsf validation with annotations
> > >
> > >
> > >
> > > hello leonardo,
> > >
> > > concerning myfaces-commons-sev-en:
> > > i don't agree. it's similar if you suggest to merge myfaces-orchestra
> > > with myfaces-commons. - in my opinion that's not a good idea.
> > > sev-en should stay independent!
> > >
> > > + commons-sev-en sounds strage. :)
> > > (the pronunciation isn't [sev] ... [en] - it's like the 7 in english)
> > >
> > > regards,
> > > gerhard
> > >
> > >  2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
> > >
> > >
> > > I have tried the demo on my workstation, and in my opinion is a very
> > > cool idea and this should be on myfaces :)
> > >
> > > The idea of include with myfaces-commons sounds better that put this
> > > on orchestra (someone could want to use this only). Maybe
> > > myfaces-commons-sev-en.
> > >
> > > regards
> > >
> > > Leonardo Uribe
> > >
> > >
> > >
> > > On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > hello andrew,
> > >
> > > sev-en is completely independent of orchestra or the idea behind it.
> > >
> > > regards,
> > > gerhard
> > >
> > >  2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:
> > >
> > > Since this is currently supported in Seam and Orchestra is a Seam
> > > spin-

Re: [proposal] jsf validation with annotations

[Hazem Saleh]

Hello,
Iam just suggesting a standard way of validation that we are going to
implement in the next days which can be useful later for JSF or EJB
projects.
This project is currently a subproject of the apache commons project.
IMHO if sev-en can support JSR-303 annotations, this will be great!
Thank you.


On Mon, Apr 7, 2008 at 10:24 PM, Gerhard Petracek <
[EMAIL PROTECTED]> wrote:

> hello,
>
> (the sev-en core doesn't provide specific annotations.
> maybe there will be an annotation module to support jsr 303 annotations,
> which might act as adapter for the project you mentioned.)
>
> or are you suggesting to publish sev-en as a sub-project of the commons
> project?
>
> regards,
> gerhard
>
>
>
> 2008/4/7, Hazem Saleh <[EMAIL PROTECTED]>:
>
> > Hi All...
> >
> >   There is already an ongoing activity to implement JSR#303 -
> > http://www.jcp.org/en/jsr/detail?id=303 - and we started it as an Apache
> > Commons Sandbox project. Following links for discussion threads and the svn
> > repo of the new project:
> >
> > http://thread.gmane.org/gmane.comp.jakarta.commons.devel/102655
> >
> > http://thread.gmane.org/gmane.comp.jakarta.commons.devel/102683
> >
> > http://svn.apache.org/repos/asf/commons/sandbox/validator2/
> >
> > IMHO this will be a good base for more specific validation requirements,
> > like JSF or EJB specific validations.
> >
> >
> > On Sat, Apr 5, 2008 at 2:02 PM, Gerhard Petracek <
> > [EMAIL PROTECTED]> wrote:
> >
> > > hello cagatay,
> > >
> > > i see your point. however, i don't agree. to keep it short:
> > > i don't like the idea to restrict sev-en to orchestra.
> > >
> > > don't get me wrong - orchestra is really great!
> > > however, it isn't alone out there.
> > > (e.g. spring web flow and much more)
> > >
> > > if sev-en is a goody or not is in the eye of the beholder.
> > > i would say e.g.: the possible jpa support is a goody of sev-en.
> > > (the core of sev-en doesn't depend on jpa or something else. the core
> > > depends only on the jsf api and at the moment on commons-logging ;))
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2008/4/4, Cagatay Civici <[EMAIL PROTECTED]>:
> > >
> > > > Hi,
> > > >
> > > > I think Orchestra is kinda out of it's original scope, Mario and
> > > > Simon couldn't resist and add many cool useful features like 
> > > > viewController,
> > > > dynaForm and more that are not related to conversations and persistence.
> > > >
> > > > Orchestra is becoming our alternative to seam, sev-en is a goodie
> > > > right? So rather than a seperate project, I've no problem if it gets 
> > > > merged
> > > > in Orchestra, just my 2 cents, it's up to further discussion.
> > > >
> > > > Cagatay
> > > >
> > > > On Fri, Apr 4, 2008 at 9:57 PM, Kito D. Mann <[EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED]
> > > > > *Sent:* Friday, April 04, 2008 2:47 PM
> > > > > *To:* MyFaces Development; [EMAIL PROTECTED]
> > > > > *Subject:* Re: [proposal] jsf validation with annotations
> > > > >
> > > > >
> > > > >
> > > > > hello kito,
> > > > >
> > > > > you can put every extension into a "commons" module.
> > > > >
> > > > > I see what you're saying. I suppose the main issue is the size of
> > > > > the module, and the number of perceived users.
> > > > >
> > > > > To be honest, I think Tomahawk is a better place for it, since
> > > > > Tomahawk contains a lot of stuff that belongs in the JSF core, like 
> > > > > some
> > > > > basic validators.
> > > > >
> > > > > orchestra is about conversations and persistence
> > > > > and
> > > > > sev-en is about validation (simple and cross-component validation)
> > > > > at the moment i'm not aware of the difference.
> > > > >
> > > > > it might be ok to put specific sev-en annotation modules into the
> > > > > commons module (as i said - they are independent of the sev-en core).
> >

Re: The pdfExport component released ;)

[Hazem Saleh]

ok thanks all, I will check it out.

On Wed, Apr 9, 2008 at 3:48 AM, Zubin Wadia <[EMAIL PROTECTED]> wrote:

> https://xhtmlrenderer.dev.java.net/
>
>
> On Tue, Apr 8, 2008 at 9:44 PM, Martin Marinschek <
> [EMAIL PROTECTED]> wrote:
>
> > Hi Hazem,
> >
> > I have just helped implementing a PDF export in Credit-Suisse (I have
> > to say it is proprietory code, though) - and what we did was using
> > Flying-Saucer. You might want to check it out.
> >
> > regards,
> >
> > Martin
> >
> > On Mon, Apr 7, 2008 at 12:39 PM, Hazem Saleh <[EMAIL PROTECTED]>
> > wrote:
> > > Hi Alexander,
> > > I will do these changes as soon as I complete the excel and pdf export
> > > integration.
> > > Your suggestions are really nice!
> > > Thank you!
> > >
> > >
> > >
> > > On Mon, Apr 7, 2008 at 9:24 AM, Jesse Alexander (KSFH 323)
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > >
> > > >
> > > > Hi
> > > >
> > > > From the sample code it seems that your component will just put the
> > > content of one table
> > > > into the PDF.
> > > >
> > > > For the PDF-export it would make sense to also allow
> > > > - multiple tables
> > > > - forms
> > > > - even complete views
> > > > to be exportable. Would this require a big refactoring to be
> > possible?
> > > >
> > > > regards
> > > > Alexander
> > > >
> > > >
> > > > 
> > >  From: Hazem Saleh [mailto:[EMAIL PROTECTED]
> > > > Sent: Saturday, April 05, 2008 3:23 AM
> > > > To: MyFaces Development
> > > > Subject: The pdfExport component released ;)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hi guys,
> > > > Iam pleased to tell you that the (PDFExport) component is finished.
> > > > It works like the (excelExport) component.
> > > >
> > > > for example)
> > > > 
> > > > 
> > > > 
> > > >
> > > > Here is the patch url :
> > > > https://issues.apache.org/jira/browse/TOMAHAWK-1229
> > > >
> > > > Thanks all :).
> > > > --
> > > > Hazem Ahmed Saleh Ahmed
> > > > http://www.jroller.com/page/HazemBlog
> > >
> > >
> > >
> > > --
> > > Hazem Ahmed Saleh Ahmed
> > > http://www.jroller.com/page/HazemBlog
> >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Hazem Saleh - Invitation to be a MyFaces Committer

[Hazem Saleh]

Dear Cagatay,
- I already signed and sent the ICLA.

- Here are my first three choices :
1. hazems
2. hazem.saleh
3. hazem_saleh

Thank you!

On Mon, Apr 7, 2008 at 3:29 PM, Cagatay Civici <[EMAIL PROTECTED]>
wrote:

> Dear Hazem,
>
> On behalf of the Apache MyFaces PMC, I would like to extend an
> invitation to become a MyFaces Committer. If you might be interested,
> please be sure to review the How the ASF Works pages.
>
> * http://apache.org/foundation/how-it-works.html
>
> along with the MyFaces PMC rules
>
> * http://myfaces.apache.org/project_management/bylaws.html
>
> If you decide to accept the invitation, the first step would be to
> file an Individual Contributor License Agreement (if you haven't done
> so already). If you have an intellectual property agreement with your
> employer, they may also need to file a corporate agreement
>
> * http://apache.org/licenses/cla-corporate.txt
>
> The next step would be to send me your first three choices for an
> Apache account name. Once the account is setup, you would be able to
> commit to the MyFaces repository.
>
> We do hope that you will be able to join us. And, we do thank you for
> your sustained efforts in helping us build not only great software,
> but a great community.
>
> Regards,
> Cagatay
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Exporter comes finally to the scene :)

[Hazem Saleh]

Hi Team,
Iam pleased to tell you that I integrated both the excelExport and the
pdfExport components into
one single component called (exporter).

Till now, it exports the contents of DataTables to EXCEL or PDF files.

Here is an example of usage)




Here is the patch URL:
https://issues.apache.org/jira/browse/TOMAHAWK-1231

Thanks all very much.
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Exporter comes finally to the scene :)

[Hazem Saleh]

Hi Team,
Generated file is now depending on the mime type :) .
Here is an example of usage)



Thanks all for your suggestions.

On Fri, Apr 18, 2008 at 5:45 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> Hi Team,
> Iam pleased to tell you that I integrated both the excelExport and the
> pdfExport components into
> one single component called (exporter).
>
> Till now, it exports the contents of DataTables to EXCEL or PDF files.
>
> Here is an example of usage)
> 
> 
> 
>
> Here is the patch URL:
> https://issues.apache.org/jira/browse/TOMAHAWK-1231
>
> Thanks all very much.
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog




-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Exporter comes finally to the scene :)

[Hazem Saleh]

Hi Matzew,
What is the problem with the previous syntax :-




On Fri, Apr 18, 2008 at 6:57 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> I would  instead of:
> 
>
> 
>
> expect something like:
>
> 
>
> 
>
> On Fri, Apr 18, 2008 at 6:49 PM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
> > Hi Team,
> > Generated file is now depending on the mime type :) .
> >
> >  Here is an example of usage)
> >  
> >  
> >  
> > Thanks all for your suggestions.
> >
> >
> >
> > On Fri, Apr 18, 2008 at 5:45 AM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
> > > Hi Team,
> > > Iam pleased to tell you that I integrated both the excelExport and the
> > pdfExport components into
> > > one single component called (exporter).
> > >
> > > Till now, it exports the contents of DataTables to EXCEL or PDF files.
> > >
> > > Here is an example of usage)
> > > 
> > > 
> > > 
> > >
> > > Here is the patch URL:
> > > https://issues.apache.org/jira/browse/TOMAHAWK-1231
> > >
> > > Thanks all very much.
> > > --
> > > Hazem Ahmed Saleh Ahmed
> > > http://www.jroller.com/page/HazemBlog
> >
> >
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Tomahawk Calendar component refactored!

[Hazem Saleh]

Hi Team,
I did refactoring for the Tomahawk Calendar component as its renderer class
was very huge.
Here is the patch, please apply if you have some time :
https://issues.apache.org/jira/browse/TOMAHAWK-1235
Thanks all.
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Exporter comes finally to the scene :)

[Hazem Saleh]

Hi Matzew,
I followed the previous pattern of the excelExport component.
So IMO, I think it is not odd for the component users.

On Fri, Apr 18, 2008 at 7:41 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:

> On Fri, Apr 18, 2008 at 7:02 PM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
> > Hi Matzew,
> > What is the problem with the previous syntax :-
> >
> > 
> > 
> >  
>
> I thought that the exporter would be an ActionListener.
> Therefore embedding it inside an ActionSource(2) component
> would make sense.
>
> I think it is odd, the nest the button inside a comp, to do the export.
> Nesting the exporter inside the button makes more sense, since
> the button performs the action. So IMO it should be ActionListener.
>
> -M
>
>
>
> >
> >
> >
> > On Fri, Apr 18, 2008 at 6:57 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
> > wrote:
> > > Hi,
> > >
> > > I would  instead of:
> > >
> > > 
> > >
> > > 
> > >
> > > expect something like:
> > >
> > > 
> > >
> > > 
> > >
> > >
> > >
> > >
> > > On Fri, Apr 18, 2008 at 6:49 PM, Hazem Saleh <[EMAIL PROTECTED]>
> > wrote:
> > > > Hi Team,
> > > > Generated file is now depending on the mime type :) .
> > > >
> > > >  Here is an example of usage)
> > > >  
> > > >  
> > > >  
> > > > Thanks all for your suggestions.
> > > >
> > > >
> > > >
> > > > On Fri, Apr 18, 2008 at 5:45 AM, Hazem Saleh <[EMAIL PROTECTED]>
> > wrote:
> > > > > Hi Team,
> > > > > Iam pleased to tell you that I integrated both the excelExport and
> the
> > > > pdfExport components into
> > > > > one single component called (exporter).
> > > > >
> > > > > Till now, it exports the contents of DataTables to EXCEL or PDF
> files.
> > > > >
> > > > > Here is an example of usage)
> > > > > 
> > > > > 
> > > > > 
> > > > >
> > > > > Here is the patch URL:
> > > > > https://issues.apache.org/jira/browse/TOMAHAWK-1231
> > > > >
> > > > > Thanks all very much.
> > > > > --
> > > > > Hazem Ahmed Saleh Ahmed
> > > > > http://www.jroller.com/page/HazemBlog
> > > >
> > > >
> > > >
> > > > --
> > > > Hazem Ahmed Saleh Ahmed
> > > > http://www.jroller.com/page/HazemBlog
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > mail: matzew-at-apache-dot-org
> > >
> >
> >
> >
> > --
> >
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Exporter comes finally to the scene :)

[Hazem Saleh]

OK, I will apply this soon with Cagatay!

On 4/19/08, Cagatay Civici <[EMAIL PROTECTED]> wrote:
>
> Agree with Matzew, action listener way looks better.
>
> It'll also help making it work with client side state saving.
>
> On Sat, Apr 19, 2008 at 11:11 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
> wrote:
>
> > On Sat, Apr 19, 2008 at 9:22 AM, Hazem Saleh <[EMAIL PROTECTED]>
> > wrote:
> > > Hi Matzew,
> > > I followed the previous pattern of the excelExport component.
> > > So IMO, I think it is not odd for the component users.
> >
> >
> > well, perhaps personal choice.
> >
> > Take this:
> >
> > http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/tr_fileDownloadActionListener.html
> >
> > that is (somewhat) similar and other libs do it in a similar fashion.
> > I don't care that strong,
> > but looks like the "old" component did it already... well not correct
> > ;-)
> > In sandbox there is a way to change this, outside of sandbox not, but
> > do what you want.
> > Was just a suggestion ;-)
> >
> > -M
> >
> > >
> > >
> > >
> > > On Fri, Apr 18, 2008 at 7:41 PM, Matthias Wessendorf <
> > [EMAIL PROTECTED]>
> > > wrote:
> > >
> > > >
> > > > On Fri, Apr 18, 2008 at 7:02 PM, Hazem Saleh <[EMAIL PROTECTED]>
> > > wrote:
> > > > > Hi Matzew,
> > > > > What is the problem with the previous syntax :-
> > > > >
> > > > > 
> > > > > 
> > > > >  
> > > >
> > > > I thought that the exporter would be an ActionListener.
> > > > Therefore embedding it inside an ActionSource(2) component
> > > > would make sense.
> > > >
> > > > I think it is odd, the nest the button inside a comp, to do the
> > export.
> > > > Nesting the exporter inside the button makes more sense, since
> > > > the button performs the action. So IMO it should be ActionListener.
> > > >
> > > > -M
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Apr 18, 2008 at 6:57 PM, Matthias Wessendorf <
> > [EMAIL PROTECTED]>
> > > > > wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I would  instead of:
> > > > > >
> > > > > > 
> > > > > >
> > > > > > 
> > > > > >
> > > > > > expect something like:
> > > > > >
> > > > > > 
> > > > > >
> > > > > > 
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Apr 18, 2008 at 6:49 PM, Hazem Saleh <
> > [EMAIL PROTECTED]>
> > > > > wrote:
> > > > > > > Hi Team,
> > > > > > > Generated file is now depending on the mime type :) .
> > > > > > >
> > > > > > >  Here is an example of usage)
> > > > > > >  
> > > > > > >  
> > > > > > >  
> > > > > > > Thanks all for your suggestions.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Apr 18, 2008 at 5:45 AM, Hazem Saleh <
> > [EMAIL PROTECTED]>
> > > > > wrote:
> > > > > > > > Hi Team,
> > > > > > > > Iam pleased to tell you that I integrated both the
> > excelExport and
> > > the
> > > > > > > pdfExport components into
> > > > > > > > one single component called (exporter).
> > > > > > > >
> > > > > > > > Till now, it exports the contents of DataTables to EXCEL or
> > PDF
> > > files.
> > > > > > > >
> > > > > > > > Here is an example of usage)
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > >
> > > > > > > > Here is the patch URL:
> > > > > > > > https://issues.apache.org/jira/browse/TOMAHAWK-1231
> > > > > > > >
> > > > > > > > Thanks all very much.
> > > > > > > > --
> > > > > > > > Hazem Ahmed Saleh Ahmed
> > > > > > > > http://www.jroller.com/page/HazemBlog
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Hazem Ahmed Saleh Ahmed
> > > > > > > http://www.jroller.com/page/HazemBlog
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > >
> > > > > > further stuff:
> > > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > > mail: matzew-at-apache-dot-org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Hazem Ahmed Saleh Ahmed
> > > > > http://www.jroller.com/page/HazemBlog
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > >
> > > >
> > > > Matthias Wessendorf
> > > >
> > > > further stuff:
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > mail: matzew-at-apache-dot-org
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Hazem Ahmed Saleh Ahmed
> > > http://www.jroller.com/page/HazemBlog
> >
> >
> >
> >
> > --
> >  Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > mail: matzew-at-apache-dot-org
> >
> >
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] sev-en as a new myfaces sub-project

[Hazem Saleh]

+1 for me.
It is a nice project that could be extended easily in the future.

On Sun, Apr 20, 2008 at 5:57 PM, Gerhard Petracek <
[EMAIL PROTECTED]> wrote:

> +1
>
> regards,
> gerhard
>
>
>
> 2008/4/20, Gerhard Petracek <[EMAIL PROTECTED]>:
>
> > hello,
> >
> > as requested i published the source code of the sev-en preview some days
> > ago (details at: [1]).
> >
> > we discussed whether or not we should start a new myfaces sub-project.
> >
> > so let's vote!
> > (there will be a separated discussion + vote concerning the name.)
> >
> >
> > ---
> > [ ] +1 for: sev-en should become a myfaces sub-project
> > [ ] +0
> > [ ] -1 for: sev-en shouldn't become a myfaces sub-project
> >
> > ---
> >
> > regards,
> > gerhard
> >
> > [1]
> > http://www.nabble.com/-proposal--jsf-validation-with-annotations-to16483341.html#a16747103
> >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: possible replacement for our kupu based html editor

[Hazem Saleh]

Hi Werner,
It doesn't work for me on FF2.

On 4/22/08, Werner Punz <[EMAIL PROTECTED]> wrote:
> Guys
> have a look at this amazing editor
> http://www.cdolivet.net/editarea/editarea/exemples/exemple_full.html
>
> the best, the code is under apache license!!!
>
> Werner
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: possible replacement for our kupu based html editor

[Hazem Saleh]

Hi Werner,
It works for me after removing some plug-ins from FF2.
I can start working on it when I have sometime.
But what is the new name u suggest for the new TextEditor?


On 4/22/08, Werner Punz <[EMAIL PROTECTED]> wrote:
> Hazem Saleh schrieb:
> > Hi Werner,
> > It doesn't work for me on FF2.
> >
> > On 4/22/08, Werner Punz <[EMAIL PROTECTED]> wrote:
> >> Guys
> >> have a look at this amazing editor
> >> http://www.cdolivet.net/editarea/editarea/exemples/exemple_full.html
> >>
> >> the best, the code is under apache license!!!
> >>
> >> Werner
> >>
> >>
> >
> >
> Check your browser settings FF2 is exactly what I am using to view it :-)
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: possible replacement for our kupu based html editor

[Hazem Saleh]

Werner,
This is great!

On 4/23/08, Werner Punz <[EMAIL PROTECTED]> wrote:
> Actually our t:htmlEditor edit control (dont ask the exact name for it)
> which is rather old and based on a kupu sourcebase which originated from
> the pre GPL/LGPL times of the editor.
> Did not know that s: alread has a html editor as well. Anyway yesterday
>I got the dojo html editor up and running in my dojo components project
> so we soon will have another option.
> I will make everything public around end of may, so that we can start a
> discussion where we are going to put the code.
>
> I do not want to open it earlier because I want to have a solid codebase
> before
> others can start to build around it.
> (Especially the base frameworks and code templates are still heavily
> under construction)
>
> Werner
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Pending on the following patch!

[Hazem Saleh]

Hi Team,

Iam pending on applying the following patch :
https://issues.apache.org/jira/browse/TOMAHAWK-1231

I cannot add new code before applying this patch to avoid conflicts.
Would you please apply it when u have sometime ?
I cannot apply now as Iam still pending on the account.

Thanks.
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Pending on the following patch!

[Hazem Saleh]

Hi Leonardo,

I just wanted to have the two components integrated on the source
repository.
So that Me and Cagatay can start applying Matzew's idea.

Thanks!


On Wed, Apr 23, 2008 at 8:55 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:

> Hi Hazem
>
> Do you want to implement the suggestion of Matthias, about be the
> h:commandButton or commandLink to surround the exporter? or you think that
> it is better as is right now? I'm not committed this by that reason (better
> make sure what this looks like).
>
> regards
>
> Leonardo Uribe
>
>
> On Wed, Apr 23, 2008 at 1:43 PM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
>
> > Hi Team,
> >
> > Iam pending on applying the following patch :
> > https://issues.apache.org/jira/browse/TOMAHAWK-1231
> >
> > I cannot add new code before applying this patch to avoid conflicts.
> > Would you please apply it when u have sometime ?
> > I cannot apply now as Iam still pending on the account.
> >
> > Thanks.
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

CAPTCHA component - Enhancement #3 - Adding width, height attributes to CAPTCHA.

[Hazem Saleh]

Hi Team,

Please apply this patch when you have someTime.
https://issues.apache.org/jira/browse/TOMAHAWK-1238

Thanks!
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Reminder: Tomahawk Calendar component refactored!

[Hazem Saleh]

-- Forwarded message --
From: Hazem Saleh <[EMAIL PROTECTED]>
Date: Sat, Apr 19, 2008 at 4:19 AM
Subject: Tomahawk Calendar component refactored!
To: MyFaces Development 


Hi Team,
I did refactoring for the Tomahawk Calendar component as its renderer class
was very huge.
Here is the patch, please apply if you have some time :
https://issues.apache.org/jira/browse/TOMAHAWK-1235
Thanks all.
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: new name for sev-en

[Hazem Saleh]

+1 for separated core jar.

On Thu, Apr 24, 2008 at 3:52 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:

> I guess I'm wondering if *core* and the annotations couldn't be in the same
> jar.
>
> I suppose the JSR-303 jar is fine.
>
> As for the naming of the JSR-303 jar, if a new JSR modifies an existing
> spec, I needs to b e backward compatible.  So yeah, just having a later
> version of your same Jar should suffice for most projects.  Some oddities
> between JSF11 and JSF12 notwithstanding.  :)
>
>
> On Thu, Apr 24, 2008 at 12:27 AM, Gerhard Petracek <
> [EMAIL PROTECTED]> wrote:
>
>> hello scott,
>>
>> there might be fewer jar-files.
>> i know what you mean. that's one of several reasons why i suggested an own
>> sub-project.
>> at least there should be 3 jar-files:
>> - core
>> - a separated annotation module for our annotations
>> - a separated module for jsr 303
>>
>> there will be other jsr 303 impl. out there. so users are free to choose
>> the impl. they prefer.
>> + if they choose an other impl. of jsr 303, they can use sev-en for the
>> rest (= our annotations and/or custom annotations).
>>
>> (+ maybe we will need a sandbox module.)
>>
>> we could use one jar-file (instead of two) for validation and
>> cross-validation. there are advantages and also disadvantages to do that.
>>
>> @jsr 303 within the name:
>> that's ok for me. i also thought about it. so we have to differ within the
>> version number.
>> if there will be other jsr's about bean validation, we might need further
>> jar-files. i don't know how compatible future versions of the bean
>> validation jsr will be.
>> so users are free to choose which jsr they would like to use.
>> it's just the question if we indicate the jsr version with the name or the
>> version number.
>> maybe there will be a jsr303-api jar-file which contains
>> javax.annotation.[...] (comparable to jsr 250).
>> that's the reason i also thought about an indication within the name.
>> however, i'm also ok with your suggestion.
>>
>> @1.1 branch:
>> that's true - nevertheless there will be two different cores. even though
>> one of it is within the branch.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2008/4/24 Scott O'Bryan <[EMAIL PROTECTED]>:
>>
>> Couple of things.
>>> Can any of this be consolidated into fewer jars?  I'm worried that the
>>> jars in the commons project are starting to look TOO segmented and
>>> functionality that is similar is not being put into a common jar.  I haven't
>>> had time to take a look at Sev-en, but provided the framework does not
>>> "automatically" add significant overhead to the processing of the lifecycle,
>>> there should be no issues if it exists, unused, in the classpath..  We have
>>> several options here, the code could live in the validators or, if people
>>> feel it will add significant overhead or dependencies, maybe one other
>>> project.
>>>
>>> As for the JSR-303, I strongly suggest AGAINST using the JSR number in
>>> your project name..  Why?  When this spec gets updated, a new JSR will be
>>> created and then your jar has no reflection on reality because my guess it
>>> you wouldn't necessarily want to change it.  Instead you might just want to
>>> call it "bean-validation".
>>>
>>> Lastly, the commons project trunk is JSF 1.2, I think Matthias has a 1.1
>>> branch and things are backported as needed.  I would essentially put your
>>> 1.1 work into that branch so it can be versioned with the rest of the 1.1
>>> commons projects.
>>>
>>> Other then that, like Andrew, I've got enough on my plate ATM...
>>>
>>> Scott
>>>
>>>
>>> Andrew Robinson wrote:
>>>
 Sounds like fun, but I've already put enough on my plate :) Perhaps in
 the future.

 On Wed, Apr 23, 2008 at 4:45 PM, Gerhard Petracek
 <[EMAIL PROTECTED]> wrote:


> hello,
>
> 'sev-en' is just the intermediate (code-)name -> let's find a final
> name.
>
> there will be some modules within commons-[new name] (which means
> several
> jar files).
>
> e.g.:
>
> required to use sev-en:
> commons-[new name]-core (currently one for jsf 1.1 and one for jsf 1.2)
>
> optional:
> commons-[new name]-validation (annotations + validation strategies,...
> and
> also the validation strategy to support jpa validation)
>  commons-[new name]-crossvalidation (annotations + validation
> strategies,
> ...)
> commons-[new name]-jsr303 (validation strategies to support jsr 303,
> ...)
>
> are there volunteers to join the development?
>
> regards,
>  gerhard
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>

>>>
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>

The Media component

[Hazem Saleh]

Hi Team,

The media component is now up and running on Tomahawk sandbox.

*Here is an example of usage)*


*Here is the patch url :*
https://issues.apache.org/jira/browse/TOMAHAWK-1247

Thanks!

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] Release of myfaces core 1.2.3

[Hazem Saleh]

+1 for me :)

On Thu, May 8, 2008 at 7:00 PM, Grant Smith <[EMAIL PROTECTED]> wrote:

> +1 looks good :)
>
>
> On Wed, May 7, 2008 at 4:41 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
>
>> +1!
>>
>>
>> On Wed, May 7, 2008 at 6:39 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
>>
>>> Hi,
>>>
>>> I was running the needed tasks to get the 1.2.3 release of Apache
>>> MyFaces core out.
>>>
>>> The artifacts passed all TCK test.
>>>
>>> Please note that this vote concerns all of the following parts:
>>>  1. Maven artifact group "org.apache.myfaces.shared" v3.0.3  [1]
>>>  2. Maven artifact group "org.apache.myfaces.core" v1.2.3  [1]
>>>
>>> The artifacts are deployed to my private Apache account ([1] and [3] for
>>> binary and source packages).
>>>
>>> The release notes could be found at [4].
>>>
>>> Also the clirr test does not show binary incompatibilities with
>>> myfaces-api.
>>>
>>> Please take a look at the "1.2.3" artifacts and vote!
>>>
>>> Please note: This vote is "majority approval" with a minimum of three
>>> +1 votes (see [3]).
>>>
>>> 
>>> [ ] +1 for community members who have reviewed the bits
>>> [ ] +0
>>> [ ] -1 for fatal flaws that should cause these bits not to be released,
>>>  and why..
>>> 
>>>
>>> Thanks,
>>> Leonardo Uribe
>>>
>>> [1] 
>>> http://people.apache.org/~lu4242/myfaces123
>>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>>> [3] 
>>> http://people.apache.org/~lu4242/myfaces123binsrc
>>> [4]
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&styleName=Html&version=12313144
>>>
>>
>>
>
>
> --
> Grant Smith
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Adobe Flex components as MyFaces JSF components

[Hazem Saleh]

On Thu, May 8, 2008 at 10:33 AM, Simon Kitching <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> Jihoon Kim schrieb:
> > Hi!
> >
> > I was hoping if someone can take a look at a recent contribution that
> > I have made to the sandbox and see if it is something that I should
> > spend more of my free time with=>
> > https://issues.apache.org/jira/browse/TOMAHAWK-1250
> >
> > I have detailed much about the contribution within the Jira, but in a
> > nutshell it is to give users capability in creating Adobe Flex
> > components as MyFaces JSF components. So users would create the
> > components as normal JSF components and the contribution will create
> > the necessary SWF files and etcetera and link the values of the
> > components back to the managed beans using JSON+Javascript and
> > etcetera.
> >
> > One caveat is that users will need to download the free Adobe Flex SDK
> > to C:\Program Files\flexSDK or /usr/local/bin/flexSDK [haven't tested
> > on linux yet].
> >
> > I thought it would be an interesting set of components and if it is
> > something that seems to have some potential I will fine tune the code
> > more and give additional capabilities within the components. I have
> > tried to keep to some of the standards within the myfaces project by
> > including tons of .xml files for tld attributes and have attached a
> > patch for set of files and a zip for others [since there exists
> > multiple directories and files within them].
> >
>
> Thanks very much for offering this code to the myfaces project.
>
> I had a quick look yesterday, and the code seems to be very nicely
> written. I'm sure it will be useful to many people.
>
> Before this becomes part of a MyFaces project, however, there are a few
> questions to answer:
> a) Abobe flex is a proprietary product. Therefore, is a wrapper for it
> suitable as an ASF project?
> b) Does the code comply with the ASF legal rules regarding licensing?
> c) Is there a large enough development community to keep this code
> maintained?
> d) What project should the code be included in?
>
> == (a)
>
> The ASF always uses the Apache License 2.0 (AL2.0). This is meant to be
> a "business friendly" license, in that code under this license can be
> included in proprietory products. However in general the ASF does try to
> promote open source over proprietory products.
>
> As far as I know, Flex is completely proprietory to Adobe, and this
> wrapper code has no other purpose than allowing this proprietory code to
> be used. Therefore I'm not sure that it is in the spirit of ASF to host
> it here.
>
> == (b)
>
> The ASF has a strict rule that no code hosted in the apache svn
> repository can contain
>   import some.gpl.api
>
> I'm reasonably sure that the same rule bans "import" of packages whose
> license is not compatible with AL2.0.
>
> I can't see any such calls in the provided code; it seems that the code
> just outputs HTML statements that happen to reference Flex plugins
> (which would probably be ok). Can you confirm that nowhere in the java
> code are any "import" statements of adobe java libs?
>
> == (c)
>
> The ASF differs from sourceforge, etc., in that it is serious about
> long-term maintenance of the projects it hosts. This means ensuring that
> there before any code becomes an official ASF project it has a group of
> people willing to maintain it. Are there other people who are willing to
> keep this code valid, and respond to bugreports etc?
>
> == (d)
>
> The patch is written so that the code is part of the Tomahawk project.
> However I don't think this would be the best place for it. The people
> who use tomahawk will not usually want this code, and the people who
> want this code will often not want the rest of tomahawk.
>
> And in addition, I personally would like to see tomahawk put into
> "maintenance only" mode, with the best bits being moved instead into the
> new "myfaces commons" modules.
>
>
> ==
>
> Please don't take this as a rejection; this is just my initial thoughts.
> Hopefully other people will comment as well. As most of the developers
> on this list are very busy it may take a week or so for people to get
> around to evaluating such a large chunk of code.
>
> Note that even if the consensus is that this code is not appropriate for
> MyFaces or Apache, it still looks very useful and we would all wish you
> success with the project no matter where it gets hosted.
>
> Regards,
> Simon
>
>
I think we haven't any problems with the Adobe Flex licence, it is
(MPL) :
http://labs.adobe.com/wiki/index.php/Flex:Open_Source#License
http://people.apache.org/~rubys/3party.html

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Adobe Flex components as MyFaces JSF components

[Hazem Saleh]

On Thu, May 8, 2008 at 7:33 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> On Thu, May 8, 2008 at 10:33 AM, Simon Kitching <[EMAIL PROTECTED]>
> wrote:
>
>> Hi,
>>
>> Jihoon Kim schrieb:
>> > Hi!
>> >
>> > I was hoping if someone can take a look at a recent contribution that
>> > I have made to the sandbox and see if it is something that I should
>> > spend more of my free time with=>
>> > https://issues.apache.org/jira/browse/TOMAHAWK-1250
>> >
>> > I have detailed much about the contribution within the Jira, but in a
>> > nutshell it is to give users capability in creating Adobe Flex
>> > components as MyFaces JSF components. So users would create the
>> > components as normal JSF components and the contribution will create
>> > the necessary SWF files and etcetera and link the values of the
>> > components back to the managed beans using JSON+Javascript and
>> > etcetera.
>> >
>> > One caveat is that users will need to download the free Adobe Flex SDK
>> > to C:\Program Files\flexSDK or /usr/local/bin/flexSDK [haven't tested
>> > on linux yet].
>> >
>> > I thought it would be an interesting set of components and if it is
>> > something that seems to have some potential I will fine tune the code
>> > more and give additional capabilities within the components. I have
>> > tried to keep to some of the standards within the myfaces project by
>> > including tons of .xml files for tld attributes and have attached a
>> > patch for set of files and a zip for others [since there exists
>> > multiple directories and files within them].
>> >
>>
>> Thanks very much for offering this code to the myfaces project.
>>
>> I had a quick look yesterday, and the code seems to be very nicely
>> written. I'm sure it will be useful to many people.
>>
>> Before this becomes part of a MyFaces project, however, there are a few
>> questions to answer:
>> a) Abobe flex is a proprietary product. Therefore, is a wrapper for it
>> suitable as an ASF project?
>> b) Does the code comply with the ASF legal rules regarding licensing?
>> c) Is there a large enough development community to keep this code
>> maintained?
>> d) What project should the code be included in?
>>
>> == (a)
>>
>> The ASF always uses the Apache License 2.0 (AL2.0). This is meant to be
>> a "business friendly" license, in that code under this license can be
>> included in proprietory products. However in general the ASF does try to
>> promote open source over proprietory products.
>>
>> As far as I know, Flex is completely proprietory to Adobe, and this
>> wrapper code has no other purpose than allowing this proprietory code to
>> be used. Therefore I'm not sure that it is in the spirit of ASF to host
>> it here.
>>
>> == (b)
>>
>> The ASF has a strict rule that no code hosted in the apache svn
>> repository can contain
>>   import some.gpl.api
>>
>> I'm reasonably sure that the same rule bans "import" of packages whose
>> license is not compatible with AL2.0.
>>
>> I can't see any such calls in the provided code; it seems that the code
>> just outputs HTML statements that happen to reference Flex plugins
>> (which would probably be ok). Can you confirm that nowhere in the java
>> code are any "import" statements of adobe java libs?
>>
>> == (c)
>>
>> The ASF differs from sourceforge, etc., in that it is serious about
>> long-term maintenance of the projects it hosts. This means ensuring that
>> there before any code becomes an official ASF project it has a group of
>> people willing to maintain it. Are there other people who are willing to
>> keep this code valid, and respond to bugreports etc?
>>
>> == (d)
>>
>> The patch is written so that the code is part of the Tomahawk project.
>> However I don't think this would be the best place for it. The people
>> who use tomahawk will not usually want this code, and the people who
>> want this code will often not want the rest of tomahawk.
>>
>> And in addition, I personally would like to see tomahawk put into
>> "maintenance only" mode, with the best bits being moved instead into the
>> new "myfaces commons" modules.
>>
>>
>> ==
>>
>> Please don't take this as a rejection; this is just my initial thoughts.
>> Hopefully other people will comment as well. As most of the de

Exporter new syntax discussion

[Hazem Saleh]

Hi Team,

After I started modifying of the Exporter component syntax,
*
To be like this :**


 
*
Some guys didnot like this new syntax, and they preferred the current one :
*


*
I need your input regarding this.
(+1) for supporting the new syntax.
(-1) for supporting the old syntax.

Thanks!

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Exporter new syntax discussion

[Hazem Saleh]

On Thu, May 8, 2008 at 9:01 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> Hi Team,
>
> After I started modifying of the Exporter component syntax,
> *
> To be like this :**
> 
>fileType="XLS"/>
>  
> *
> Some guys didnot like this new syntax, and they preferred the current one :
> *
> 
> 
> *
> I need your input regarding this.
> (+1) for supporting the new syntax.
> (-1) for supporting the old syntax.
>
> Thanks!
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog


(-1) for :).

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Exporter new syntax discussion

[Hazem Saleh]

Hi Gerald,

No special reason, I just asked people who use this component and they
disliked the new syntax.

On Thu, May 8, 2008 at 9:29 PM, Gerald Müllan <[EMAIL PROTECTED]> wrote:

> Hi,
>
> i would prefer the new syntax since it seems to be more natural to me.
>
> Similar to an updateActionListener; the command component fires the
> listener embedded inside.
>
> So, +1
>
> Any special reason why breaking the common sense?
>
> cheers,
>
> Gerald
>
> On Thu, May 8, 2008 at 8:01 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > Hi Team,
> >
> > After I started modifying of the Exporter component syntax,
> >
> > To be like this :
> > 
> >  >   fileType="XLS"/>
> >  
> >
> > Some guys didnot like this new syntax, and they preferred the current one
> :
> > 
> > 
> > 
> >
> > I need your input regarding this.
> > (+1) for supporting the new syntax.
> > (-1) for supporting the old syntax.
> >
> > Thanks!
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>
> --
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Adobe Flex components as MyFaces JSF components

[Hazem Saleh]

On Fri, May 9, 2008 at 12:08 AM, Grant Smith <[EMAIL PROTECTED]> wrote:

>
>
>
>> (c)
>> I assume that the group which will maintain this code will increase in
>> number, because personally I think it to be one of the areas that has
>> a lot of potential and do think that it will be able to bring a lot of
>> additional ideas to the project. For example, I initially wanted to
>> create components that detect the browser setting and either direct
>> application to components based on Dojo or Adobe Flex, but thought
>> this would be better for separation and perhaps in the future there
>> could be components that performs this action.
>>
>>
> I agree with this. The work I'm involved with privately is increasingly
> interested in Flex. This would be a good bridging opportunity for MyFaces.
>
> --
> Grant Smith
>

I totally agree with Grant words.
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Exporter new syntax discussion

[Hazem Saleh]

Hi Team,

Iam pleased to tell you that the new syntax is applied to the Exporter
component.
*
The syntax now is :*


 

*Here is the patch url:
*https://issues.apache.org/jira/browse/TOMAHAWK-1252

BTW, the exporter now supports the client state saving :).
Thanks all :).

On Fri, May 9, 2008 at 12:13 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:

> I totally agree with Gerald.
> I think the old syntax is just wrong.
> So... +1
>
> Sent from my iPod.
>
> Am 08.05.2008 um 20:29 schrieb "Gerald Müllan" <[EMAIL PROTECTED]>:
>
>
>  Hi,
>>
>> i would prefer the new syntax since it seems to be more natural to me.
>>
>> Similar to an updateActionListener; the command component fires the
>> listener embedded inside.
>>
>> So, +1
>>
>> Any special reason why breaking the common sense?
>>
>> cheers,
>>
>> Gerald
>>
>> On Thu, May 8, 2008 at 8:01 PM, Hazem Saleh <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Hi Team,
>>>
>>> After I started modifying of the Exporter component syntax,
>>>
>>> To be like this :
>>> 
>>>   >> fileType="XLS"/>
>>> 
>>>
>>> Some guys didnot like this new syntax, and they preferred the current one
>>> :
>>> 
>>>   
>>> 
>>>
>>> I need your input regarding this.
>>> (+1) for supporting the new syntax.
>>> (-1) for supporting the old syntax.
>>>
>>> Thanks!
>>>
>>> --
>>> Hazem Ahmed Saleh Ahmed
>>> http://www.jroller.com/page/HazemBlog
>>>
>>
>>
>>
>> --
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: new name for sev-en

[Hazem Saleh]

+1 for myfaces-commons-checker.

On Sat, May 10, 2008 at 1:53 PM, Gerhard Petracek <
[EMAIL PROTECTED]> wrote:

> do you have a further suggestion?
> maybe a bit more fancy?
>
> e.g. one of the suggestions i heard is:
> myfaces-commons-checker
>
> maybe it's a new starting point for further suggestions.
>
> regards,
> gerhard
>
>
>
> 2008/4/29 Scott O'Bryan <[EMAIL PROTECTED]>:
>
> How about "convalidi".  It's validate in Italian (I think).
>>
>> Gerhard Petracek wrote:
>>
>>> hello scott,
>>>
>>> do you have a suggestion for a short and fancy name?
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2008/4/27 Scott O'Bryan <[EMAIL PROTECTED] >> >>:
>>>
>>>+1 to not naming it validations.  There is already a commons
>>>validator.
>>>
>>>-0 to including core in the name
>>>
>>>Strong -1 to including JSR in the project name.  A jar is nearly
>>>an enhancement number for java.  You wouln't name your project
>>>something like MyFaces-1234 after a Jira ticket number.
>>>
>>>
>>>On Apr 26, 2008, at 10:25 AM, "Gerhard Petracek"
>>><[EMAIL PROTECTED] >
>>>wrote:
>>>
>>> hello alexander,

i got your idea.
however, i hope we will find a short and fancy name.

if we don't have 'core' within the name, i think we have to find
something else than just 'validation'.
otherwise it will be a bit confusing for users due to the fact
that the core itself doesn't validate.
concrete validation logic is located within the
independent/optional modules.
the target is to have a core which provides the infrastructure
and which encapsulates the specifics of the jsf version.
furthermore, the core is independent of specific annotations. the
optional modules provide the concrete annotations and/or
validation logic (independent of the jsf version).
(reason for and/or: we don't provide the annotations of jpa nor
of jsr 303 - we just provide the validation strategies for these
external annotations.)

@myfaces-commons-validation-annotations:
it isn't a pure annotation module - it also provides the
validation strategies and much more.
(in the case of the jpa validation support it just provides the
validation strategy.)
moreover, i would suggest that we rename seven-validation to
seven-ext-validation or a bit shorter: seven-extval (for extended
validation)
or something similar which indicates that these are our
annotations (and so on).

@myfaces-commons-validation-jsr303:
i'm fine with both jsr303 (my original suggestion) or bean-validation

the names of our compromise so far:

myfaces-commons-[new name]
(= the core)

myfaces-commons-[new name]-validation
(= our annotations + validation strategies incl. cross-component
validation infrastructure and also the jpa validation strategy,...)

myfaces-commons-[new name]-bean-validation
(= the infrastructure and validation strategies to support jsr 303)

fancy suggestions for [new name] are welcome.
(we need some suggestions to open a vote.)

or what's about something different
it isn't my favourite - however, it might be an impulse for other
suggestions.

e.g.:
myfaces-commons-validation-core
myfaces-commons-validation-extval
myfaces-commons-validation-jsr303 (or bean-validation)

(i prefer an independent name.)

regards,
gerhard



2008/4/25 Jesse Alexander (KSFH 336)
<[EMAIL PROTECTED]
>:


we are getting side-tracked...
let's find a name within this thread! :)

validation ?
->
myfaces-commons-validation
myfaces-commons-validation-annotations (was -validation)
myfaces-commons-validation-jsr303(was bean-validation)
kind regards
Alexander




--
http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

>>>
>>>
>>>
>>>
>>> --
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>
>>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Adobe Flex components as MyFaces JSF components

[Hazem Saleh]

If the idea is accepted, I can give a part of my time to implement the
standard converters, validators and other stuff.
IMO, alchemy is a very nice name ( I really like :) ).
+1 for Gerhard idea.

On Wed, May 14, 2008 at 1:20 AM, Jihoon Kim <[EMAIL PROTECTED]> wrote:

> Hi thanks for the feedback!
>
> Yes, I was intending to support the other jsf artifacts such as
> converters and validators in the future. In the contribution, I did
> create the components for Flex's validators and converters. But since
> they belong in a swf file, they technically are actual jsf components
> [in order to keep to the design]. Yet since all components that take
> input and updates the model extend from UIInput, I do not think there
> will be too many issues in supporting the regular jsf converters and
> validators. Of course when the contribution does get accepted, I do
> plan on investing my free time in creating support for standard
> converters and validators as well as other areas that I wish to
> improve upon.
>
> I think that's a good idea, since in the future I was hoping to check
> out javafx and other technology as well.
>
> Thanks!!!
>
> On Tue, May 13, 2008 at 2:27 PM, Gerhard Petracek
> <[EMAIL PROTECTED]> wrote:
> > hello,
> >
> > i had just a very quick look at it.
> >
> > do you plan to support existing jsf artifacts (e.g. converters,
> > validators,...)?
> >
> > @subproject and name:
> > for each topic you have to start at least a vote.
> >
> > what's about the following idea:
> > let's start a subproject for component libs like alchemy.
> > in the future it might be nice to have also a component lib for e.g.
> > javafx,...
> >
> > [new subproject]
> >  |_ [alchemy]
> >   |_[...]
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2008/5/13 Jihoon Kim <[EMAIL PROTECTED]>:
> >
> >
> > >
> > > >  I would suggest that the best place would be as a new subproject,
> like
> > > >  "orchestra" or "portlet bridge" are. It would definitely belong in
> the
> > > >  MyFaces family (rather than anywhere else in Apache) but I don't
> think
> > > >  it fits as part of Tomahawk. As I noted earlier, people who use
> > tomahawk
> > > >  won't always want Flex, and people who want Flex won't always want
> the
> > > >  other tomahawk components.
> > > >
> > > >  It could also be a new "myfaces commons" module, but we haven't
> really
> > > >  figured out how to structure those anyway. And it isn't really a
> > "common
> > > >  module", but a component library just like tomahawk is.
> > >
> > > So is there any documentation in regards to how a code becomes a
> > > subproject of MyFaces? I would like to possibly look into that area,
> > > since if that is the path that might be taken; I would like to know of
> > > the process ahead of time.
> > >
> > > I did previously read through the process within the incubator, but
> > > wasn't sure if that was solely for a standalone project or applies to
> > > subproject as well.
> > >
> > > In the case that the contribution does get accepted and does become a
> > > subproject, I even have a name that I would like to propose, which is
> > > alchemy.
> > >
> > > Thanks!!!
> > > --
> > > Sincerely,
> > >
> > > Ji Hoon Kim
> > >
> >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
>
>
>
> --
> Sincerely,
>
> Ji Hoon Kim
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Adobe Flex components as MyFaces JSF components

[Hazem Saleh]

Ji,
Would you please initiate a vote on the group to see whether to include
(alchemy) as a MyFaces subproject or not.
Thanks!

On Wed, May 14, 2008 at 3:20 PM, Jihoon Kim <[EMAIL PROTECTED]> wrote:

> Just for clarification, when mentioning proprietary tool, Simon is
> referring to Adobe Flash Player. Flex itself has been open sourced.
>
>
> On Tue, May 13, 2008 at 11:23 PM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > I'd vote -1 on accepting this project into myfaces.
> >
> > I don't think the idea of a bridge between jsf and flex is a bad one,
> > but I don't believe that a wrapper for a proprietory tool belongs here
> > at Apache. I would suggest sourceforge instead. Myfaces members who are
> > interested in flex (eg Hazem, Grant) can of course equally well work
> > with a sourceforge project.
> >
> > We could certainly add a link from our pages pointing at "related
> > projects", such as this one, either on the wiki or on the main site
> > itself. And I think it would be quite reasonable for release
> > announcements to be posted on the myfaces user list; people subscribed
> > to the myfaces list might be interested.
> >
> > BTW, until javafx is propertly open-source, I would probably also vote
> > -1 to a wrapper around that being hosted here.
> >
> > Regards,
> > Simon
> >
> > Hazem Saleh schrieb:
> >> If the idea is accepted, I can give a part of my time to implement the
> >> standard converters, validators and other stuff.
> >> IMO, alchemy is a very nice name ( I really like :) ).
> >> +1 for Gerhard idea.
> >>
> >> On Wed, May 14, 2008 at 1:20 AM, Jihoon Kim <[EMAIL PROTECTED]
> >> <mailto:[EMAIL PROTECTED]>> wrote:
> >>
> >> Hi thanks for the feedback!
> >>
> >> Yes, I was intending to support the other jsf artifacts such as
> >> converters and validators in the future. In the contribution, I did
> >> create the components for Flex's validators and converters. But
> since
> >> they belong in a swf file, they technically are actual jsf
> components
> >> [in order to keep to the design]. Yet since all components that take
> >> input and updates the model extend from UIInput, I do not think
> there
> >> will be too many issues in supporting the regular jsf converters and
> >> validators. Of course when the contribution does get accepted, I do
> >> plan on investing my free time in creating support for standard
> >> converters and validators as well as other areas that I wish to
> >> improve upon.
> >>
> >> I think that's a good idea, since in the future I was hoping to
> check
> >> out javafx and other technology as well.
> >>
> >> Thanks!!!
> >>
> >> On Tue, May 13, 2008 at 2:27 PM, Gerhard Petracek
> >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> >> wrote:
> >> > hello,
> >> >
> >> > i had just a very quick look at it.
> >> >
> >> > do you plan to support existing jsf artifacts (e.g. converters,
> >> > validators,...)?
> >> >
> >> > @subproject and name:
> >> > for each topic you have to start at least a vote.
> >> >
> >> > what's about the following idea:
> >> > let's start a subproject for component libs like alchemy.
> >> > in the future it might be nice to have also a component lib for
> e.g.
> >> > javafx,...
> >> >
> >> > [new subproject]
> >> >  |_ [alchemy]
> >> >   |_[...]
> >> >
> >>
> >> >
> >> >
> >> > >
> >> > > >  I would suggest that the best place would be as a new
> >> subproject, like
> >> > > >  "orchestra" or "portlet bridge" are. It would definitely
> >> belong in the
> >> > > >  MyFaces family (rather than anywhere else in Apache) but I
> >> don't think
> >> > > >  it fits as part of Tomahawk. As I noted earlier, people who
> use
> >> > tomahawk
> >> > > >  won't always want Flex, and people who want Flex won't
> >> always want the
> >> > > >  other tomahawk components.
> >> > &

Re: [VOTE] To create a subproject alchemy under MyFaces for the contribution that integrates Adobe Flex components as MyFaces JSF components

[Hazem Saleh]

+1

On Thu, May 15, 2008 at 6:34 AM, Jihoon Kim <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Since I wanted to have a clear understanding of community's viewpoint
> of whether the contribution should be part of MyFaces subproject, I am
> starting this vote.
>
> The contribution details are noted within the following JIRA link =>
>
> https://issues.apache.org/jira/browse/TOMAHAWK-1250
>
> In a nutshell, it is to give users capability in creating Adobe Flex
> components as MyFaces JSF components. So users would create the
> components as normal JSF components and the contribution will create
> the necessary SWF files and etcetera and link the values of the
> components back to the managed beans using JSON+Javascript and
> etcetera.
>
> In the above discussion "Adobe Flex components as MyFaces JSF
> components", one note that was raised is that Adobe Flash Player is
> proprietary while Adobe Flex has been open sourced.
>
> Personally, since I did see an another project within Apache that did
> create Adobe PDF and since Adobe Flash Player is ubiquitous; I guess I
> underplayed the fact that Adobe Flash Player is proprietary.
>
> Anyway, thanks to everyone and I will wait to hear the consensus
> regarding this contribution!!!
>
> --
> Sincerely,
>
> Ji Hoon Kim
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [COMMUNITY] MyFaces += Hazem Saleh

[Hazem Saleh]

Thanks all very much.
Iam really very proud to be one of this great team.

On Sat, May 17, 2008 at 12:20 AM, Grant Smith <[EMAIL PROTECTED]> wrote:

> Welcome !
>
>
> On Fri, May 16, 2008 at 2:08 PM, Gerhard Petracek <
> [EMAIL PROTECTED]> wrote:
>
>> welcome!
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2008/5/16 Paul Spencer <[EMAIL PROTECTED]>:
>>
>> Hazem,
>>> Welcome to MyFaces.
>>>
>>> Paul Spencer
>>>
>>>
>>> Manfred Geiler wrote:
>>>
>>>> The Myfaces PMC is proud to announce a new addition to our community.
>>>>
>>>> Please welcome Hazem Saleh as the newest MyFaces committer!
>>>> Hazem is an active member of the myfaces community, he contributed
>>>> some cool components like captcha, password strength and provided many
>>>> patches.
>>>> He is also involved in the Apache Myfaces and Facelets book.
>>>>
>>>> @Hazem: Please add yourself to the Master-POM at
>>>>
>>>> https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml
>>>>
>>>> --Manfred
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>
>
>
>
> --
> Grant Smith
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

about the pprPanelGroup component

[Hazem Saleh]

Hi Team,

I was asking what is the missing things to promote the pprPanelGroup
component to Tomahawk.
It is really a very nice component and I can spend more time next days to
complete any missing thing.
Thanks all.

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: about the pprPanelGroup component

[Hazem Saleh]

Hi Guys,

I will try to detach the component from Dojo so it can be promoted.

On Tue, May 20, 2008 at 1:36 PM, Werner Punz <[EMAIL PROTECTED]> wrote:

> Gerald Müllan schrieb:
>
>> Hi Hazem,
>>
>> Werner wants to migrate dojo to the latest release and tie it out of
>> tomahawk.
>> pprPanelGroup is relying on dojo, so i think it would be better to
>> wait until werner has finished his work.
>>
>>  Well it will be roughly a month before I am going to commit the first
> code
> (Sorry for not doing it public currently but I do not want to have people
> starting to use it before I do not have the core in place properly).
>
> But thinking of it it would make sense to remove the dojo dependencies out
> of the component and replace it with custom code.
>
> I think the component itself would make perfect sense in core tomahawk.
>
> So Hazem if you want to spend some time with it, this could be a perfect
> thing to do.
>
> The long term plan is to get dojo stuff into its own subproject and have
> Tomahawk as dependency free as possible.
>
>
> Werner
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: myfaces groovy support first pre alpha showcase

[Hazem Saleh]

+1 for Gerhard idea.

On Tue, May 20, 2008 at 8:17 PM, Gerhard Petracek <
[EMAIL PROTECTED]> wrote:

> hello werner,
>
> currently we have several nice extensions.
>
> + we discussed that 'commons' should stay stable.
>
> -> my suggestion (instead of the commons project):
> let's setup just one further subproject.
>
> name of the subproject:
> e.g.: myfaces-extensions
>
> which contains something like (in chronological order):
> - myfaces-extensions-aspectel
> - myfaces-extensions-seven
> - myfaces-extensions-scripting
>
> regards,
> gerhard
>
>
>
> 2008/5/20 Werner Punz <[EMAIL PROTECTED]>:
>
> Ok now to the question.
>> Now that I am out of the experimentation phase
>> I want to merge my stuff into myfaces
>> lem is where exactly.
>> Suggestions?
>> Is the commons project already in place?
>>
>>
>> Werner
>>
>>
>> Werner Punz schrieb:
>>
>>  Hello everyone
>>>
>>> this is a crude first pre alpha release of the myfaces groovy support
>>> you can get it from
>>>
>>> http://people.apache.org/~werpu/myfaces-groovy.zip
>>>
>>> you can make a build with mvn clean install
>>> and then drop the war into a servlet runner
>>> once expanded and running
>>> you can start to hack
>>>
>>> the groovy files under WEB-INF/groovy/
>>>
>>> and you should see the changes without restarting the webapp
>>> you even should be able to add properties, methods or remove them on the
>>> fly without any server restart
>>>
>>> (never mind the startup errors this is intended, since
>>> myfaces kicks in twice, and the first time it complains about not finding
>>> the classes)
>>>
>>> Have in mind, this is pre alpha stuff i am not entirely where I want to
>>> be but it works.
>>>
>>> Please keep in mind following things:
>>>
>>> artefacts only start to reload once their sources
>>> have been altered after startup, no change, no reload!
>>>
>>> Renderers work on page refresh
>>> Components refresh at creation time
>>> (Sorry this is a jsf imposed limitation for now)
>>>
>>> Beans basically everything coming through the el should reload
>>> at reference time (the properties are kept intact so never mind any
>>> dependencies)
>>>
>>> non jsfs Groovy - Groovy references should reload at creation time (this
>>> is a feature which is untested yet, so it might not work yet, I had it
>>> running though)
>>>
>>> Long running objects like the view handler etc.. should reload
>>> on call time, if changed, which means at least once per refresh, if
>>> changed
>>> if you have properties which have to survive those changes
>>> please expose them, I try to keep the properties intact after reloading
>>> but with private or protected properties I do not have a chance.
>>> But since most long running artefacts in jsf are stateless this is a non
>>> issue.
>>>
>>> For component development use facelets, I cannot kickstart
>>> the jsp artefacts.
>>>
>>> You can mix and blend java groovy and compiled groovy during development,
>>> but for compilation use the groovy stub compilation feature.
>>> During production I would recommend to remove the groovy kickstarter
>>> and compile everything!
>>>
>>>
>>> Ok here are some technical details.
>>>
>>> I managed to pull this off without changing a single line of core
>>> myfaces code.
>>> What I did was to add my own factories which on the correct placed
>>> applied some "aop", which means it either was reloading objects on the
>>> fly with new code and applying their old properties or adding proxies
>>> which basically did the same, depending on the artefact.
>>>
>>> On the groovy side of things I did the same in a more transparent way to
>>> be able to reload referenced objects.
>>> I originally wanted to apply this method to all artefacts, but as soon as
>>> I shifted the altered classes to the javarealm I lost all the groovy meta
>>> info needed for this mechanism. So I kept it on the groovy side of things.
>>>
>>> What I did on the startup side was to reinitialize myfaces with my own
>>> classloader which resolves the groovy files if present.
>>> And as well as the sun guys did for the RI I had to add my own
>>> servletfilter which checked for replaced classloaders and reapplied the
>>> groovy classloader on the fly (tomcat for instance replaces the classloader
>>> once it hits a custom one at certain stages)
>>>
>>> Ok have in mind that this code is pre alpha stage, but nevertheless you
>>> can see the potential of it once you try it out.
>>> But please do not use it in a production system.
>>> (And no it does not work in portlets yet)
>>>
>>> And please no complaints about dirty code yet it is not done yet ;-)
>>>
>>>
>>>
>>> Werner
>>>
>>>
>>>
>>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces




-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] myfaces-extensions as a new myfaces sub-project

[Hazem Saleh]

++1 :).

On Mon, Jun 2, 2008 at 9:52 AM, Gerhard Petracek <[EMAIL PROTECTED]>
wrote:

> +1
>
> 2008/6/2 Gerhard Petracek <[EMAIL PROTECTED]>:
>
> hello,
>>
>> we discussed whether or not we should start a new myfaces sub-project
>> (details at: [1] and [2]).
>>
>> name:
>> myfaces-extensions
>>
>> description:
>> place for small innovative projects (which are beyond the current "std.
>> mechanisms" of jsf)
>> currently these small projects are: aspect-el, sev-en and scripting
>>
>> so - after the positive response let's vote!
>> (there will be a separated discussion + vote concerning the names.)
>>
>>
>> ---
>> [ ] +1 for: myfaces-extensions should become a myfaces sub-project
>> [ ] +0
>> [ ] -1 for: myfaces-extensions shouldn't become a myfaces sub-project
>>
>> ---
>>
>> regards,
>> gerhard
>>
>> [1]
>> http://www.nabble.com/-PROPOSAL--myfaces-extensions-to17466179.html#a17466179
>> [2]
>> http://www.nabble.com/Re%3A--PROPOSAL--myfaces-extensions-p17474665.html
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] To have MyFaces Alchemy as a subproject

[Hazem Saleh]

+1 for having FlexFaces as a subproject. Having this project under MyFaces
IMO will be a very good addition to the project.

On Tue, Jun 3, 2008 at 6:30 PM, Grant Smith <[EMAIL PROTECTED]> wrote:

> I'm voting +1 for this subproject. I don't see the current Adobe Flash
> dependency as a roadblock, and I don't think other contributers here should
> either. Adobe have recently made significant leaps into open sourcing their
> products and I feel it to be a matter of time before supporting technologies
> evolve due to their recent commitment to open source.
>
> Even if this were not the case, we already have things like the the PDF and
> Excel exporters, which by Simon's argument we should not support.
>
>
> On Tue, Jun 3, 2008 at 1:24 AM, [EMAIL PROTECTED] <
> [EMAIL PROTECTED]> wrote:
>
>> I'm still voting -1 on having a flash-based project within MyFaces
>> unless someone can show that this code works with a non-proprietory
>> Flash player.
>>
>> I'd be happy to see this project succeed, but not here at Apache. This
>> foundation exists to promote open source software, not provide wrappers
>> for proprietory tools.
>>
>> Regards,
>> Simon
>>
>>
>
>
> --
> Grant Smith
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Tomahawk next release!

[Hazem Saleh]

Hi Team,

I just want to ask when can we Tomahawk next release ?
We can list all the pending issues (if we have), so we can work on to have a
near release of the library.

Thanks all!
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: Tomahawk next release!

[Hazem Saleh]

Hi Paul,

Where can I get Tomahawk 1.1.7 RoadMap?
Thanks!

On Tue, Jun 3, 2008 at 9:36 PM, Paul Spencer <[EMAIL PROTECTED]> wrote:

> Hazen,
> For a list of pending issues, look at the roadmap for 1.1.7-SNAPSHOT.
>
> Paul Spencer
>
>
>
> Hazem Saleh wrote:
>
>> Hi Team,
>>
>> I just want to ask when can we Tomahawk next release ?
>> We can list all the pending issues (if we have), so we can work on to have
>> a
>> near release of the library.
>>
>> Thanks all!
>>
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] Apply myfaces builder plugin for myfaces core 1.2 and tomahawk 1.2

[Hazem Saleh]

+1

On Wed, Jun 4, 2008 at 12:01 PM, Bruno Aranda <[EMAIL PROTECTED]> wrote:

> +1 (both points)
>
> 2008/6/4 Leonardo Uribe <[EMAIL PROTECTED]>:
> > +1
> >
> > On Tue, Jun 3, 2008 at 10:55 PM, Leonardo Uribe <[EMAIL PROTECTED]>
> wrote:
> >>
> >> Hi
> >>
> >> The code necessary to tomahawk 1.2 is ready for commit.
> >>
> >> For do this, it is necessary to apply myfaces builder plugin on myfaces
> >> core 1.2. The work on myfaces core 1.2 can be seen here:
> >>
> >>
> >>
> http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/builder_plugin/bigtest/core_trunk_1.2.x/
> >>
> >> There is still some details that I'm solving (I want to remove
> >> myfaces-faces-plugin, and generate everything with
> myfaces-builder-plugin),
> >> but the code is ready for a vote. It uses source annotations (instead
> >> doclets on 1.1, see myfaces-builder-annotations submodule). For do this
> >> first it was modified temporally myfaces-faces-plugin for generate
> >> myfaces-builder-annotations automatically and then do the upgrade (and
> add
> >> additional missing info). Clirr report does not show any problems.
> >>
> >> The code for tomahawk 1.2 can be seen here
> >>
> >>
> >>
> http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/builder_plugin/bigtest/tomahawk12_trunk/
> >>
> >> It uses the new unpack mojo that makes very easy the maintain of this
> >> project. The idea of unpack goal is extract tomahawk 1.1 parts of code
> and
> >> resources automatically, making this project relatively small.
> >>
> >> In conclusion, the vote is for this parts:
> >>
> >> 1. Apply myfaces-builder-plugin on myfaces core 1.2 (necessary for build
> >> correct myfaces-metadata.xml for tomahawk 1.2)
> >> 2. Add two modules called core12 and sandbox/core12 on tomahawk, that
> >> contains 1.2 specific code for tomahawk.
> >>
> >> Suggestions are welcome.
> >>
> >> regards
> >>
> >> Leonardo Uribe
> >>
> >>
> >>
> >
> >
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

About the PPRPanelGroup component defects

[Hazem Saleh]

Hi Team,

Yesterday, I reviewed the defects opened on the PPRPanelGroup component :
https://issues.apache.org/jira/browse/TOMAHAWK-1226
https://issues.apache.org/jira/browse/TOMAHAWK-1227
https://issues.apache.org/jira/browse/TOMAHAWK-1228

And I could not replicate them, Is there anyone has a previous experience
with
these defects?
I just need examples that replicate these bugs!

Thanks all very much.

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

[VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

Hi Team,

After integration the pdfExport and the excelExport components into the
exporterActionListener component,
improving its syntax and completing its documentation.

I wish to promote this component to the next Tomahawk release.

[+1] for agreeing with promoting the component to the next Tomahawk release.
[-1] for disagreeing with promoting the component to the next Tomahawk
release.

Thanks all very much!

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

+1

On Thu, Jun 5, 2008 at 4:45 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> Hi Team,
>
> After integration the pdfExport and the excelExport components into the
> exporterActionListener component,
> improving its syntax and completing its documentation.
>
> I wish to promote this component to the next Tomahawk release.
>
> [+1] for agreeing with promoting the component to the next Tomahawk
> release.
> [-1] for disagreeing with promoting the component to the next Tomahawk
> release.
>
> Thanks all very much!
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog




-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

[VOTE] promoting the captcha component to Tomahawk

[Hazem Saleh]

Hi Team,

After completing the CAPTCHA documentation.

I wish to promote this component to the next Tomahawk release.

[+1] for agreeing with promoting the component to the next Tomahawk release.
[-1] for disagreeing with promoting the component to the next Tomahawk
release.

Thanks all very much!

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the captcha component to Tomahawk

[Hazem Saleh]

+1

On Thu, Jun 5, 2008 at 11:12 PM, Werner Punz <[EMAIL PROTECTED]> wrote:

> +1
>
> Hazem Saleh schrieb:
>
>  Hi Team,
>>
>> After completing the CAPTCHA documentation.
>>
>> I wish to promote this component to the next Tomahawk release.
>>
>> [+1] for agreeing with promoting the component to the next Tomahawk
>> release.
>> [-1] for disagreeing with promoting the component to the next Tomahawk
>> release.
>>
>> Thanks all very much!
>>
>> --
>> Hazem Ahmed Saleh Ahmed
>> http://www.jroller.com/page/HazemBlog
>>
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

Hi Volker,

I have a future plan of extending the functionality of this component to
make it aware of the current displayed Tomahawk dataTable page.
I mean, the generated reports will be aware of Tomahawk related classes.
Thanks.

On Thu, Jun 5, 2008 at 6:14 PM, Volker Weber <[EMAIL PROTECTED]> wrote:

> Hi,
>
> any reason to move this to tomahawk and not into commons?
>
> Are there any dependencies to tomahawk or a specific renderkit?
>
> I had not looked into, but if this is what it sounds like :
> A actionListener which could added to any UICommand component,
> which renders binary data from a UIData component,
> than there is no reason to add this to a html-renderkit library.
>
> -1 in this case for tomahawk.
> -0 otherwise
>
>
> Regards,
>Volker
>
>
>
> 2008/6/5 Hazem Saleh <[EMAIL PROTECTED]>:
> > Hi Team,
> >
> > After integration the pdfExport and the excelExport components into the
> > exporterActionListener component,
> > improving its syntax and completing its documentation.
> >
> > I wish to promote this component to the next Tomahawk release.
> >
> > [+1] for agreeing with promoting the component to the next Tomahawk
> release.
> > [-1] for disagreeing with promoting the component to the next Tomahawk
> > release.
> >
> > Thanks all very much!
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>
> --
> inexso - information exchange solutions GmbH
> Bismarckstraße 13 | 26122 Oldenburg
> Tel.: +49 441 4082 356 |
> FAX: +49 441 4082 355 | www.inexso.de
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

I still totally agree with Leonardo, Iam not seeing that Tomahawk should
depend on myfaces-commons to use the exporterListener component.
Iam still (+1).

On Fri, Jun 6, 2008 at 3:53 AM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:

> The actual layout of myfaces-commons is this:
>
> myfaces-commons-validators
> myfaces-commons-converters
> myfaces-commons-utils
>
> There is no a project like:
>
> myfaces-commons-listeners
>
> myfaces-commons is tied to 1.2, so if some converter or validator is in
> tomahawk 1.1, on tomahawk 1.2 this should be referred to myfaces-commons
> (makes easy for existing tomahawk user upgrade and do not change their
> current pages). In this case myfaces-commons should be a dependency for
> tomahawk.
>
> According to the intention of several developers, there are things of
> tomahawk that it should be on its own submodule (dojo components by example,
> converters and validators) and others in tomahawk. This issues were not be
> discussed yet, so if this is in tomahawk there is no prob.
>
> +1
>
> regards
>
> Leonardo Uribe
>
>
> On Thu, Jun 5, 2008 at 6:50 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>
>> Hi Volker,
>>
>> I have a future plan of extending the functionality of this component to
>> make it aware of the current displayed Tomahawk dataTable page.
>> I mean, the generated reports will be aware of Tomahawk related classes.
>> Thanks.
>>
>>
>> On Thu, Jun 5, 2008 at 6:14 PM, Volker Weber <[EMAIL PROTECTED]> wrote:
>>
>>> Hi,
>>>
>>> any reason to move this to tomahawk and not into commons?
>>>
>>> Are there any dependencies to tomahawk or a specific renderkit?
>>>
>>> I had not looked into, but if this is what it sounds like :
>>> A actionListener which could added to any UICommand component,
>>> which renders binary data from a UIData component,
>>> than there is no reason to add this to a html-renderkit library.
>>>
>>> -1 in this case for tomahawk.
>>> -0 otherwise
>>>
>>>
>>> Regards,
>>>Volker
>>>
>>>
>>>
>>> 2008/6/5 Hazem Saleh <[EMAIL PROTECTED]>:
>>> > Hi Team,
>>> >
>>> > After integration the pdfExport and the excelExport components into the
>>> > exporterActionListener component,
>>> > improving its syntax and completing its documentation.
>>> >
>>> > I wish to promote this component to the next Tomahawk release.
>>> >
>>> > [+1] for agreeing with promoting the component to the next Tomahawk
>>> release.
>>> > [-1] for disagreeing with promoting the component to the next Tomahawk
>>> > release.
>>> >
>>> > Thanks all very much!
>>> >
>>> > --
>>> > Hazem Ahmed Saleh Ahmed
>>> > http://www.jroller.com/page/HazemBlog
>>>
>>>
>>>
>>> --
>>> inexso - information exchange solutions GmbH
>>> Bismarckstraße 13 | 26122 Oldenburg
>>> Tel.: +49 441 4082 356 |
>>> FAX: +49 441 4082 355 | www.inexso.de
>>>
>>
>>
>>
>> --
>> Hazem Ahmed Saleh Ahmed
>> http://www.jroller.com/page/HazemBlog
>>
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

As I said before, This listener will be aware of other Tomahawk components
(The current functionality will be extended).
BTW, I don't think that I said some thing so funny!

On Fri, Jun 6, 2008 at 2:10 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:

> On Fri, Jun 6, 2008 at 12:58 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > I still totally agree with Leonardo, Iam not seeing that Tomahawk should
> > depend on myfaces-commons to use the exporterListener component.
>
> lol
> there would be no dependency...
> in an ideal world such a listener is totally independent from the used
> table
> (icefaces, tomahawk, standard, ...)
>
> So, just add it to the page (inside an actionsource(2)) and refer to the
> desired
> table. I can't see why that way such an exporter would have a dependency to
> tomahawk.
>
> > Iam still (+1).
> >
> > On Fri, Jun 6, 2008 at 3:53 AM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
> >>
> >> The actual layout of myfaces-commons is this:
> >>
> >> myfaces-commons-validators
> >> myfaces-commons-converters
> >> myfaces-commons-utils
> >>
> >> There is no a project like:
> >>
> >> myfaces-commons-listeners
> >>
> >> myfaces-commons is tied to 1.2, so if some converter or validator is in
> >> tomahawk 1.1, on tomahawk 1.2 this should be referred to myfaces-commons
> >> (makes easy for existing tomahawk user upgrade and do not change their
> >> current pages). In this case myfaces-commons should be a dependency for
> >> tomahawk.
> >>
> >> According to the intention of several developers, there are things of
> >> tomahawk that it should be on its own submodule (dojo components by
> example,
> >> converters and validators) and others in tomahawk. This issues were not
> be
> >> discussed yet, so if this is in tomahawk there is no prob.
> >>
> >> +1
> >>
> >> regards
> >>
> >> Leonardo Uribe
> >>
> >> On Thu, Jun 5, 2008 at 6:50 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> >>>
> >>> Hi Volker,
> >>>
> >>> I have a future plan of extending the functionality of this component
> to
> >>> make it aware of the current displayed Tomahawk dataTable page.
> >>> I mean, the generated reports will be aware of Tomahawk related
> classes.
> >>> Thanks.
> >>>
> >>> On Thu, Jun 5, 2008 at 6:14 PM, Volker Weber <[EMAIL PROTECTED]>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> any reason to move this to tomahawk and not into commons?
> >>>>
> >>>> Are there any dependencies to tomahawk or a specific renderkit?
> >>>>
> >>>> I had not looked into, but if this is what it sounds like :
> >>>> A actionListener which could added to any UICommand component,
> >>>> which renders binary data from a UIData component,
> >>>> than there is no reason to add this to a html-renderkit library.
> >>>>
> >>>> -1 in this case for tomahawk.
> >>>> -0 otherwise
> >>>>
> >>>>
> >>>> Regards,
> >>>>Volker
> >>>>
> >>>>
> >>>>
> >>>> 2008/6/5 Hazem Saleh <[EMAIL PROTECTED]>:
> >>>> > Hi Team,
> >>>> >
> >>>> > After integration the pdfExport and the excelExport components into
> >>>> > the
> >>>> > exporterActionListener component,
> >>>> > improving its syntax and completing its documentation.
> >>>> >
> >>>> > I wish to promote this component to the next Tomahawk release.
> >>>> >
> >>>> > [+1] for agreeing with promoting the component to the next Tomahawk
> >>>> > release.
> >>>> > [-1] for disagreeing with promoting the component to the next
> Tomahawk
> >>>> > release.
> >>>> >
> >>>> > Thanks all very much!
> >>>> >
> >>>> > --
> >>>> > Hazem Ahmed Saleh Ahmed
> >>>> > http://www.jroller.com/page/HazemBlog
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> inexso - information exchange solutions GmbH
> >>>> Bismarckstraße 13 | 26122 Oldenburg
> >>>> Tel.: +49 441 4082 356 |
> >>>> FAX: +49 441 4082 355 | www.inexso.de
> >>>
> >>>
> >>>
> >>> --
> >>> Hazem Ahmed Saleh Ahmed
> >>> http://www.jroller.com/page/HazemBlog
> >
> >
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

Hi Team,

I will suspend this vote for now.
I will start now implementing some of my future work of this component so
that no confusion can be occur.
I will be back to this thread after showing you a concrete example.
Thanks all very much.

On Fri, Jun 6, 2008 at 2:41 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> As I said before, This listener will be aware of other Tomahawk components
> (The current functionality will be extended).
> BTW, I don't think that I said some thing so funny!
>
>
> On Fri, Jun 6, 2008 at 2:10 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
> wrote:
>
>> On Fri, Jun 6, 2008 at 12:58 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>> > I still totally agree with Leonardo, Iam not seeing that Tomahawk should
>> > depend on myfaces-commons to use the exporterListener component.
>>
>> lol
>> there would be no dependency...
>> in an ideal world such a listener is totally independent from the used
>> table
>> (icefaces, tomahawk, standard, ...)
>>
>> So, just add it to the page (inside an actionsource(2)) and refer to the
>> desired
>> table. I can't see why that way such an exporter would have a dependency
>> to
>> tomahawk.
>>
>> > Iam still (+1).
>> >
>> > On Fri, Jun 6, 2008 at 3:53 AM, Leonardo Uribe <[EMAIL PROTECTED]>
>> wrote:
>> >>
>> >> The actual layout of myfaces-commons is this:
>> >>
>> >> myfaces-commons-validators
>> >> myfaces-commons-converters
>> >> myfaces-commons-utils
>> >>
>> >> There is no a project like:
>> >>
>> >> myfaces-commons-listeners
>> >>
>> >> myfaces-commons is tied to 1.2, so if some converter or validator is in
>> >> tomahawk 1.1, on tomahawk 1.2 this should be referred to
>> myfaces-commons
>> >> (makes easy for existing tomahawk user upgrade and do not change their
>> >> current pages). In this case myfaces-commons should be a dependency for
>> >> tomahawk.
>> >>
>> >> According to the intention of several developers, there are things of
>> >> tomahawk that it should be on its own submodule (dojo components by
>> example,
>> >> converters and validators) and others in tomahawk. This issues were not
>> be
>> >> discussed yet, so if this is in tomahawk there is no prob.
>> >>
>> >> +1
>> >>
>> >> regards
>> >>
>> >> Leonardo Uribe
>> >>
>> >> On Thu, Jun 5, 2008 at 6:50 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>> >>>
>> >>> Hi Volker,
>> >>>
>> >>> I have a future plan of extending the functionality of this component
>> to
>> >>> make it aware of the current displayed Tomahawk dataTable page.
>> >>> I mean, the generated reports will be aware of Tomahawk related
>> classes.
>> >>> Thanks.
>> >>>
>> >>> On Thu, Jun 5, 2008 at 6:14 PM, Volker Weber <[EMAIL PROTECTED]>
>> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> any reason to move this to tomahawk and not into commons?
>> >>>>
>> >>>> Are there any dependencies to tomahawk or a specific renderkit?
>> >>>>
>> >>>> I had not looked into, but if this is what it sounds like :
>> >>>> A actionListener which could added to any UICommand component,
>> >>>> which renders binary data from a UIData component,
>> >>>> than there is no reason to add this to a html-renderkit library.
>> >>>>
>> >>>> -1 in this case for tomahawk.
>> >>>> -0 otherwise
>> >>>>
>> >>>>
>> >>>> Regards,
>> >>>>Volker
>> >>>>
>> >>>>
>> >>>>
>> >>>> 2008/6/5 Hazem Saleh <[EMAIL PROTECTED]>:
>> >>>> > Hi Team,
>> >>>> >
>> >>>> > After integration the pdfExport and the excelExport components into
>> >>>> > the
>> >>>> > exporterActionListener component,
>> >>>> > improving its syntax and completing its documentation.
>> >>>> >
>> >>>> > I wish to promote this component to the next Tomahawk release.
>> >>>> >
>> >>>> > [+1] for agreeing with promoting the component to the next Tomahawk
>> >>>> > release.
>> >>>> > [-1] for disagreeing with promoting the component to the next
>> Tomahawk
>> >>>> > release.
>> >>>> >
>> >>>> > Thanks all very much!
>> >>>> >
>> >>>> > --
>> >>>> > Hazem Ahmed Saleh Ahmed
>> >>>> > http://www.jroller.com/page/HazemBlog
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> inexso - information exchange solutions GmbH
>> >>>> Bismarckstraße 13 | 26122 Oldenburg
>> >>>> Tel.: +49 441 4082 356 |
>> >>>> FAX: +49 441 4082 355 | www.inexso.de
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Hazem Ahmed Saleh Ahmed
>> >>> http://www.jroller.com/page/HazemBlog
>> >
>> >
>> >
>> > --
>> > Hazem Ahmed Saleh Ahmed
>> > http://www.jroller.com/page/HazemBlog
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> further stuff:
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> mail: matzew-at-apache-dot-org
>>
>
>
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

I have no problem to give non Tomahawk users the ability to use the
exporter, but I would like to use the nice Tomahawk features so that the
component can be more useful and prettier (Please wait till I show you a
near demo about the exporter and you will get my point).

On Fri, Jun 6, 2008 at 3:30 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:

> On Fri, Jun 6, 2008 at 2:28 PM, Volker Weber <[EMAIL PROTECTED]> wrote:
> > Hi Hazem,
> >
> > there is no reason why tomahawk should not depends on common-*.
> >
> > If you have a well working UIData content to exel/pdf exporter why
> > don't give non tomahawk users the ability to use it.
>
> that were exactly my reasons.
> even more, the application would require the extra commons-* stuff,
> when one want the exporter.
>
> >
> >
> > Regards,
> >Volker
> >
> > 2008/6/6 Hazem Saleh <[EMAIL PROTECTED]>:
> >> Hi Team,
> >>
> >> I will suspend this vote for now.
> >> I will start now implementing some of my future work of this component
> so
> >> that no confusion can be occur.
> >> I will be back to this thread after showing you a concrete example.
> >> Thanks all very much.
> >>
> >> On Fri, Jun 6, 2008 at 2:41 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> >>>
> >>> As I said before, This listener will be aware of other Tomahawk
> components
> >>> (The current functionality will be extended).
> >>> BTW, I don't think that I said some thing so funny!
> >>>
> >>> On Fri, Jun 6, 2008 at 2:10 PM, Matthias Wessendorf <[EMAIL PROTECTED]
> >
> >>> wrote:
> >>>>
> >>>> On Fri, Jun 6, 2008 at 12:58 PM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
> >>>> > I still totally agree with Leonardo, Iam not seeing that Tomahawk
> >>>> > should
> >>>> > depend on myfaces-commons to use the exporterListener component.
> >>>>
> >>>> lol
> >>>> there would be no dependency...
> >>>> in an ideal world such a listener is totally independent from the used
> >>>> table
> >>>> (icefaces, tomahawk, standard, ...)
> >>>>
> >>>> So, just add it to the page (inside an actionsource(2)) and refer to
> the
> >>>> desired
> >>>> table. I can't see why that way such an exporter would have a
> dependency
> >>>> to
> >>>> tomahawk.
> >>>>
> >>>> > Iam still (+1).
> >>>> >
> >>>> > On Fri, Jun 6, 2008 at 3:53 AM, Leonardo Uribe <[EMAIL PROTECTED]>
> >>>> > wrote:
> >>>> >>
> >>>> >> The actual layout of myfaces-commons is this:
> >>>> >>
> >>>> >> myfaces-commons-validators
> >>>> >> myfaces-commons-converters
> >>>> >> myfaces-commons-utils
> >>>> >>
> >>>> >> There is no a project like:
> >>>> >>
> >>>> >> myfaces-commons-listeners
> >>>> >>
> >>>> >> myfaces-commons is tied to 1.2, so if some converter or validator
> is
> >>>> >> in
> >>>> >> tomahawk 1.1, on tomahawk 1.2 this should be referred to
> >>>> >> myfaces-commons
> >>>> >> (makes easy for existing tomahawk user upgrade and do not change
> their
> >>>> >> current pages). In this case myfaces-commons should be a dependency
> >>>> >> for
> >>>> >> tomahawk.
> >>>> >>
> >>>> >> According to the intention of several developers, there are things
> of
> >>>> >> tomahawk that it should be on its own submodule (dojo components by
> >>>> >> example,
> >>>> >> converters and validators) and others in tomahawk. This issues were
> >>>> >> not be
> >>>> >> discussed yet, so if this is in tomahawk there is no prob.
> >>>> >>
> >>>> >> +1
> >>>> >>
> >>>> >> regards
> >>>> >>
> >>>> >> Leonardo Uribe
> >>>> >>
> >>>> >> On Thu, Jun 5, 2008 at 6:50 PM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
> >>>> >>>
> >>>> >>> Hi 

Re: [VOTE] name for 'seven'

[Hazem Saleh]

+1 for myfaces-extensions-seven, IMO it rocks.

On Fri, Jun 6, 2008 at 3:43 PM, Gerhard Petracek <[EMAIL PROTECTED]>
wrote:

> +1 for myfaces-extensions-seven
>
> 2008/6/6 Gerhard Petracek <[EMAIL PROTECTED]>:
>
> hello,
>>
>> there are no new name suggestions concerning 'seven' [1].
>> so i suggest to start the vote.
>>
>> the new meaning of the acronym:
>>
>> *s*imple *e*nhanced *v*alidation with *e*xtensible *n*ature
>>
>> seven will be part of myfaces-extensions [2]
>>
>> i suggest the following choices:
>> 1) myfaces-extensions-seven
>> 2) myfaces-extensions-jack
>> 3) myfaces-extensions-validator
>>
>> 
>>  [ ] +1 for the preferred name
>> [ ] +0
>> [ ] -1 to place a veto for a name
>> 
>>
>> regards,
>> gerhard
>>
>> [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg31960.html
>> [2] http://www.mail-archive.com/dev@myfaces.apache.org/msg32712.html
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the captcha component to Tomahawk

[Hazem Saleh]

Hi Team,

Thanks very much for your votes!
I will start in promoting CAPTCHA!

On Fri, Jun 6, 2008 at 8:43 PM, Grant Smith <[EMAIL PROTECTED]> wrote:

> +1
>
>
> On Fri, Jun 6, 2008 at 5:51 AM, Zubin Wadia <[EMAIL PROTECTED]> wrote:
>
>> +1
>>
>>
>> On Fri, Jun 6, 2008 at 5:59 AM, Bruno Aranda <[EMAIL PROTECTED]>
>> wrote:
>>
>>> +1
>>>
>>> 2008/6/6 Zubin Wadia <[EMAIL PROTECTED]>:
>>> > +1
>>> >
>>> > On Thu, Jun 5, 2008 at 8:44 PM, Leonardo Uribe <[EMAIL PROTECTED]>
>>> wrote:
>>> >>
>>> >> +1
>>> >>
>>> >> On Thu, Jun 5, 2008 at 6:39 PM, Hazem Saleh <[EMAIL PROTECTED]>
>>> wrote:
>>> >>>
>>> >>> +1
>>> >>>
>>> >>> On Thu, Jun 5, 2008 at 11:12 PM, Werner Punz <[EMAIL PROTECTED]>
>>> >>> wrote:
>>> >>>>
>>> >>>> +1
>>> >>>>
>>> >>>> Hazem Saleh schrieb:
>>> >>>>>
>>> >>>>> Hi Team,
>>> >>>>>
>>> >>>>> After completing the CAPTCHA documentation.
>>> >>>>>
>>> >>>>> I wish to promote this component to the next Tomahawk release.
>>> >>>>>
>>> >>>>> [+1] for agreeing with promoting the component to the next Tomahawk
>>> >>>>> release.
>>> >>>>> [-1] for disagreeing with promoting the component to the next
>>> Tomahawk
>>> >>>>> release.
>>> >>>>>
>>> >>>>> Thanks all very much!
>>> >>>>>
>>> >>>>> --
>>> >>>>> Hazem Ahmed Saleh Ahmed
>>> >>>>> http://www.jroller.com/page/HazemBlog
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Hazem Ahmed Saleh Ahmed
>>> >>> http://www.jroller.com/page/HazemBlog
>>> >
>>> >
>>>
>>
>>
>
>
> --
> Grant Smith
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

Hi Team,

I just finished one of the improvements I intended to develop for the
exporterActionListener component :
* Integration with the Tomahawk dataScroller, so that it can be allowed for
generating the only displayed dataTable page in the exported pdf or excel
file.

*- Example of usage :*





As we see in the example, the component should know the Tomahawk scroller
ID.
So I think it is not suitable to include this component in myfaces commons
as it uses Tomahawk APIs.

*Let's resume voting again :*
Now we have.
3 votes for promoting the component to Tomahawk.
2 votes for not promoting the component to Tomahawk and moving to commons.

Thanks all very much!

On Fri, Jun 6, 2008 at 6:30 PM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:

> Isn't Tomahawk already a commons set of components? It works with
> other render kits, besides some incompatibilities do to the filter
> design. I am wondering if we are attempting to put too much into
> commons.
>
> My take would be if this is a component that does any rendering it
> fits well in Tomahawk, but if it is more of a framework feature, then
> commons would be better.
>
> +0 for me though, I don't mind either approach, I'll let others decide.
>
> On Fri, Jun 6, 2008 at 6:38 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > I have no problem to give non Tomahawk users the ability to use the
> > exporter, but I would like to use the nice Tomahawk features so that the
> > component can be more useful and prettier (Please wait till I show you a
> > near demo about the exporter and you will get my point).
> >
> > On Fri, Jun 6, 2008 at 3:30 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
> > wrote:
> >>
> >> On Fri, Jun 6, 2008 at 2:28 PM, Volker Weber <[EMAIL PROTECTED]> wrote:
> >> > Hi Hazem,
> >> >
> >> > there is no reason why tomahawk should not depends on common-*.
> >> >
> >> > If you have a well working UIData content to exel/pdf exporter why
> >> > don't give non tomahawk users the ability to use it.
> >>
> >> that were exactly my reasons.
> >> even more, the application would require the extra commons-* stuff,
> >> when one want the exporter.
> >>
> >> >
> >> >
> >> > Regards,
> >> >Volker
> >> >
> >> > 2008/6/6 Hazem Saleh <[EMAIL PROTECTED]>:
> >> >> Hi Team,
> >> >>
> >> >> I will suspend this vote for now.
> >> >> I will start now implementing some of my future work of this
> component
> >> >> so
> >> >> that no confusion can be occur.
> >> >> I will be back to this thread after showing you a concrete example.
> >> >> Thanks all very much.
> >> >>
> >> >> On Fri, Jun 6, 2008 at 2:41 PM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
> >> >>>
> >> >>> As I said before, This listener will be aware of other Tomahawk
> >> >>> components
> >> >>> (The current functionality will be extended).
> >> >>> BTW, I don't think that I said some thing so funny!
> >> >>>
> >> >>> On Fri, Jun 6, 2008 at 2:10 PM, Matthias Wessendorf
> >> >>> <[EMAIL PROTECTED]>
> >> >>> wrote:
> >> >>>>
> >> >>>> On Fri, Jun 6, 2008 at 12:58 PM, Hazem Saleh <[EMAIL PROTECTED]>
> >> >>>> wrote:
> >> >>>> > I still totally agree with Leonardo, Iam not seeing that Tomahawk
> >> >>>> > should
> >> >>>> > depend on myfaces-commons to use the exporterListener component.
> >> >>>>
> >> >>>> lol
> >> >>>> there would be no dependency...
> >> >>>> in an ideal world such a listener is totally independent from the
> >> >>>> used
> >> >>>> table
> >> >>>> (icefaces, tomahawk, standard, ...)
> >> >>>>
> >> >>>> So, just add it to the page (inside an actionsource(2)) and refer
> to
> >> >>>> the
> >> >>>> desired
> >> >>>> table. I can't see why that way such an exporter would have a
> >> >>>> dependency
> >> >>>> to
> >> >>>> tomahawk.
> >> >>>>
> >> >>>> > Iam still (+1).
> >> >>>> >
> >> >>>>

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

Hi Volker,

I promise to do a separated one for commons after finishing my Tomahawk
release tasks (Although I don't think that the component will be useful if
it depends on JSF APIs only).

*A note about the commons project :*
I think we should have a clear vision or a draft plan that determines the
project objectives, scope and road map.

Thanks!

On Sun, Jun 8, 2008 at 5:16 PM, Volker Weber <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Can you create another exporterActionListener to include into comons
> for non tomahawk users?
> Or should i copy the pre 664385 svn version to commons?
>
>
> Adding the complete tomahawk.jar just for this one tool is a no go, so
> its worthless for me.
>
>
> BTW should i add knowledge about the tobago sheet paging and start a
> vote moving it to tobago?
>
> AFAIK the core of exporterActionListener is just based on jsf-api.
> It is fine to have a version which 'knows' the library specific
> extensions (t:dataScroller, tc:sheet, tr:table)
> in the subprojects, but why  should we replicate the core exporter
> sources instead of using/extending the
> plain jsf-api version from commons?
>
> We should start putting useful stuff into commons or this subproject
> will never grow.
>
>
> Regards,
>Volker
>
>
>
>
> 2008/6/8 Hazem Saleh <[EMAIL PROTECTED]>:
> > Hi Team,
> >
> > I just finished one of the improvements I intended to develop for the
> > exporterActionListener component :
> > * Integration with the Tomahawk dataScroller, so that it can be allowed
> for
> > generating the only displayed dataTable page in the exported pdf or excel
> > file.
> >
> > - Example of usage :
> >
> > 
> >  >  fileType="PDF" showDisplayedPageOnly="true"/>
> > 
> >
> > As we see in the example, the component should know the Tomahawk scroller
> > ID.
> > So I think it is not suitable to include this component in myfaces
> commons
> > as it uses Tomahawk APIs.
> >
> > Let's resume voting again :
> > Now we have.
> > 3 votes for promoting the component to Tomahawk.
> > 2 votes for not promoting the component to Tomahawk and moving to
> commons.
> >
> > Thanks all very much!
> >
> > On Fri, Jun 6, 2008 at 6:30 PM, Andrew Robinson
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> Isn't Tomahawk already a commons set of components? It works with
> >> other render kits, besides some incompatibilities do to the filter
> >> design. I am wondering if we are attempting to put too much into
> >> commons.
> >>
> >> My take would be if this is a component that does any rendering it
> >> fits well in Tomahawk, but if it is more of a framework feature, then
> >> commons would be better.
> >>
> >> +0 for me though, I don't mind either approach, I'll let others decide.
> >>
> >> On Fri, Jun 6, 2008 at 6:38 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> >> > I have no problem to give non Tomahawk users the ability to use the
> >> > exporter, but I would like to use the nice Tomahawk features so that
> the
> >> > component can be more useful and prettier (Please wait till I show you
> a
> >> > near demo about the exporter and you will get my point).
> >> >
> >> > On Fri, Jun 6, 2008 at 3:30 PM, Matthias Wessendorf <
> [EMAIL PROTECTED]>
> >> > wrote:
> >> >>
> >> >> On Fri, Jun 6, 2008 at 2:28 PM, Volker Weber <[EMAIL PROTECTED]>
> wrote:
> >> >> > Hi Hazem,
> >> >> >
> >> >> > there is no reason why tomahawk should not depends on common-*.
> >> >> >
> >> >> > If you have a well working UIData content to exel/pdf exporter why
> >> >> > don't give non tomahawk users the ability to use it.
> >> >>
> >> >> that were exactly my reasons.
> >> >> even more, the application would require the extra commons-* stuff,
> >> >> when one want the exporter.
> >> >>
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> >Volker
> >> >> >
> >> >> > 2008/6/6 Hazem Saleh <[EMAIL PROTECTED]>:
> >> >> >> Hi Team,
> >> >> >>
> >> >> >> I will suspend this vote for now.
> >> >> >> I will start now implementing some of my future work of this
> >> >> >&

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

[1] useful = very useful.

On Sun, Jun 8, 2008 at 11:46 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> Hi Volker,
>
> I promise to do a separated one for commons after finishing my Tomahawk
> release tasks (Although I don't think that the component will be useful[1]
> if it depends on JSF APIs only).
>
> *A note about the commons project :*
> I think we should have a clear vision or a draft plan that determines the
> project objectives, scope and road map.
>
> Thanks!
>
>
> On Sun, Jun 8, 2008 at 5:16 PM, Volker Weber <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> Can you create another exporterActionListener to include into comons
>> for non tomahawk users?
>> Or should i copy the pre 664385 svn version to commons?
>>
>>
>> Adding the complete tomahawk.jar just for this one tool is a no go, so
>> its worthless for me.
>>
>>
>> BTW should i add knowledge about the tobago sheet paging and start a
>> vote moving it to tobago?
>>
>> AFAIK the core of exporterActionListener is just based on jsf-api.
>> It is fine to have a version which 'knows' the library specific
>> extensions (t:dataScroller, tc:sheet, tr:table)
>> in the subprojects, but why  should we replicate the core exporter
>> sources instead of using/extending the
>> plain jsf-api version from commons?
>>
>> We should start putting useful stuff into commons or this subproject
>> will never grow.
>>
>>
>> Regards,
>>Volker
>>
>>
>>
>>
>> 2008/6/8 Hazem Saleh <[EMAIL PROTECTED]>:
>> > Hi Team,
>> >
>> > I just finished one of the improvements I intended to develop for the
>> > exporterActionListener component :
>> > * Integration with the Tomahawk dataScroller, so that it can be allowed
>> for
>> > generating the only displayed dataTable page in the exported pdf or
>> excel
>> > file.
>> >
>> > - Example of usage :
>> >
>> > 
>> > > >  fileType="PDF" showDisplayedPageOnly="true"/>
>> > 
>> >
>> > As we see in the example, the component should know the Tomahawk
>> scroller
>> > ID.
>> > So I think it is not suitable to include this component in myfaces
>> commons
>> > as it uses Tomahawk APIs.
>> >
>> > Let's resume voting again :
>> > Now we have.
>> > 3 votes for promoting the component to Tomahawk.
>> > 2 votes for not promoting the component to Tomahawk and moving to
>> commons.
>> >
>> > Thanks all very much!
>> >
>> > On Fri, Jun 6, 2008 at 6:30 PM, Andrew Robinson
>> > <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Isn't Tomahawk already a commons set of components? It works with
>> >> other render kits, besides some incompatibilities do to the filter
>> >> design. I am wondering if we are attempting to put too much into
>> >> commons.
>> >>
>> >> My take would be if this is a component that does any rendering it
>> >> fits well in Tomahawk, but if it is more of a framework feature, then
>> >> commons would be better.
>> >>
>> >> +0 for me though, I don't mind either approach, I'll let others decide.
>> >>
>> >> On Fri, Jun 6, 2008 at 6:38 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>> >> > I have no problem to give non Tomahawk users the ability to use the
>> >> > exporter, but I would like to use the nice Tomahawk features so that
>> the
>> >> > component can be more useful and prettier (Please wait till I show
>> you a
>> >> > near demo about the exporter and you will get my point).
>> >> >
>> >> > On Fri, Jun 6, 2008 at 3:30 PM, Matthias Wessendorf <
>> [EMAIL PROTECTED]>
>> >> > wrote:
>> >> >>
>> >> >> On Fri, Jun 6, 2008 at 2:28 PM, Volker Weber <[EMAIL PROTECTED]>
>> wrote:
>> >> >> > Hi Hazem,
>> >> >> >
>> >> >> > there is no reason why tomahawk should not depends on common-*.
>> >> >> >
>> >> >> > If you have a well working UIData content to exel/pdf exporter why
>> >> >> > don't give non tomahawk users the ability to use it.
>> >> >>
>> >> >> that were exactly my reasons.
>> >> >> even more, the application wou

Re: [VOTE] promoting the captcha component to Tomahawk

[Hazem Saleh]

Don :D.
Guys, you can now use CAPTCHA from Tomahawk 1.1.7 :-).
**
Thanks to all of you!

On Sun, Jun 8, 2008 at 2:53 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> Hi Team,
>
> Thanks very much for your votes!
> I will start in promoting CAPTCHA!
>
>
> On Fri, Jun 6, 2008 at 8:43 PM, Grant Smith <[EMAIL PROTECTED]> wrote:
>
>> +1
>>
>>
>> On Fri, Jun 6, 2008 at 5:51 AM, Zubin Wadia <[EMAIL PROTECTED]> wrote:
>>
>>> +1
>>>
>>>
>>> On Fri, Jun 6, 2008 at 5:59 AM, Bruno Aranda <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> 2008/6/6 Zubin Wadia <[EMAIL PROTECTED]>:
>>>> > +1
>>>> >
>>>> > On Thu, Jun 5, 2008 at 8:44 PM, Leonardo Uribe <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>
>>>> >> +1
>>>> >>
>>>> >> On Thu, Jun 5, 2008 at 6:39 PM, Hazem Saleh <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>>
>>>> >>> +1
>>>> >>>
>>>> >>> On Thu, Jun 5, 2008 at 11:12 PM, Werner Punz <[EMAIL PROTECTED]
>>>> >
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> +1
>>>> >>>>
>>>> >>>> Hazem Saleh schrieb:
>>>> >>>>>
>>>> >>>>> Hi Team,
>>>> >>>>>
>>>> >>>>> After completing the CAPTCHA documentation.
>>>> >>>>>
>>>> >>>>> I wish to promote this component to the next Tomahawk release.
>>>> >>>>>
>>>> >>>>> [+1] for agreeing with promoting the component to the next
>>>> Tomahawk
>>>> >>>>> release.
>>>> >>>>> [-1] for disagreeing with promoting the component to the next
>>>> Tomahawk
>>>> >>>>> release.
>>>> >>>>>
>>>> >>>>> Thanks all very much!
>>>> >>>>>
>>>> >>>>> --
>>>> >>>>> Hazem Ahmed Saleh Ahmed
>>>> >>>>> http://www.jroller.com/page/HazemBlog
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> Hazem Ahmed Saleh Ahmed
>>>> >>> http://www.jroller.com/page/HazemBlog
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>>
>> --
>> Grant Smith
>>
>
>
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

Great!, we now have.
4 votes for promoting the component to Tomahawk.
2 votes for not promoting the component to Tomahawk and moving to commons.

I will give more 12 hours, and will start promoting the component if the
voting is still toward the component's promotion.

Thanks all!

On Mon, Jun 9, 2008 at 5:20 AM, Zubin Wadia <[EMAIL PROTECTED]> wrote:

> +1
>
>
> On Sun, Jun 8, 2008 at 4:48 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>
>> [1] useful = very useful.
>>
>> On Sun, Jun 8, 2008 at 11:46 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>>
>>> Hi Volker,
>>>
>>> I promise to do a separated one for commons after finishing my Tomahawk
>>> release tasks (Although I don't think that the component will be useful[1]
>>> if it depends on JSF APIs only).
>>>
>>>
>>> *A note about the commons project :*
>>> I think we should have a clear vision or a draft plan that determines the
>>> project objectives, scope and road map.
>>>
>>> Thanks!
>>>
>>>
>>> On Sun, Jun 8, 2008 at 5:16 PM, Volker Weber <[EMAIL PROTECTED]> wrote:
>>>
>>>> Hi,
>>>>
>>>> Can you create another exporterActionListener to include into comons
>>>> for non tomahawk users?
>>>> Or should i copy the pre 664385 svn version to commons?
>>>>
>>>>
>>>> Adding the complete tomahawk.jar just for this one tool is a no go, so
>>>> its worthless for me.
>>>>
>>>>
>>>> BTW should i add knowledge about the tobago sheet paging and start a
>>>> vote moving it to tobago?
>>>>
>>>> AFAIK the core of exporterActionListener is just based on jsf-api.
>>>> It is fine to have a version which 'knows' the library specific
>>>> extensions (t:dataScroller, tc:sheet, tr:table)
>>>> in the subprojects, but why  should we replicate the core exporter
>>>> sources instead of using/extending the
>>>> plain jsf-api version from commons?
>>>>
>>>> We should start putting useful stuff into commons or this subproject
>>>> will never grow.
>>>>
>>>>
>>>> Regards,
>>>>Volker
>>>>
>>>>
>>>>
>>>>
>>>> 2008/6/8 Hazem Saleh <[EMAIL PROTECTED]>:
>>>> > Hi Team,
>>>> >
>>>> > I just finished one of the improvements I intended to develop for the
>>>> > exporterActionListener component :
>>>> > * Integration with the Tomahawk dataScroller, so that it can be
>>>> allowed for
>>>> > generating the only displayed dataTable page in the exported pdf or
>>>> excel
>>>> > file.
>>>> >
>>>> > - Example of usage :
>>>> >
>>>> > 
>>>> > >>> >  fileType="PDF" showDisplayedPageOnly="true"/>
>>>> > 
>>>> >
>>>> > As we see in the example, the component should know the Tomahawk
>>>> scroller
>>>> > ID.
>>>> > So I think it is not suitable to include this component in myfaces
>>>> commons
>>>> > as it uses Tomahawk APIs.
>>>> >
>>>> > Let's resume voting again :
>>>> > Now we have.
>>>> > 3 votes for promoting the component to Tomahawk.
>>>> > 2 votes for not promoting the component to Tomahawk and moving to
>>>> commons.
>>>> >
>>>> > Thanks all very much!
>>>> >
>>>> > On Fri, Jun 6, 2008 at 6:30 PM, Andrew Robinson
>>>> > <[EMAIL PROTECTED]> wrote:
>>>> >>
>>>> >> Isn't Tomahawk already a commons set of components? It works with
>>>> >> other render kits, besides some incompatibilities do to the filter
>>>> >> design. I am wondering if we are attempting to put too much into
>>>> >> commons.
>>>> >>
>>>> >> My take would be if this is a component that does any rendering it
>>>> >> fits well in Tomahawk, but if it is more of a framework feature, then
>>>> >> commons would be better.
>>>> >>
>>>> >> +0 for me though, I don't mind either approach, I'll let others
>>>> decide.
>>>> >>
>>>> >> On Fri, J

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

Hi Volker,

I think we should take the whole votes, this vote is for MyFaces community
not for only MyFaces PMC.

On Mon, Jun 9, 2008 at 2:48 PM, Volker Weber <[EMAIL PROTECTED]> wrote:

> Hi Hazem,
>
> if you count pmc votes we have
>
> 1 votes for promoting the component to Tomahawk. (werner)
> 2 votes for not promoting the component to Tomahawk and moving to
> commons. (matze and me)
>
> And after you have suspending the vote (your mail from 6.6. 14:16) i
> think you should at last restart before counting results.
>
>
> Regards,
>Volker
>
>
> 2008/6/9 Hazem Saleh <[EMAIL PROTECTED]>:
> > Great!, we now have.
> > 4 votes for promoting the component to Tomahawk.
> > 2 votes for not promoting the component to Tomahawk and moving to
> commons.
> >
> > I will give more 12 hours, and will start promoting the component if the
> > voting is still toward the component's promotion.
> >
> > Thanks all!
> >
> > On Mon, Jun 9, 2008 at 5:20 AM, Zubin Wadia <[EMAIL PROTECTED]> wrote:
> >>
> >> +1
> >>
> >> On Sun, Jun 8, 2008 at 4:48 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> >>>
> >>> [1] useful = very useful.
> >>>
> >>> On Sun, Jun 8, 2008 at 11:46 PM, Hazem Saleh <[EMAIL PROTECTED]>
> wrote:
> >>>>
> >>>> Hi Volker,
> >>>>
> >>>> I promise to do a separated one for commons after finishing my
> Tomahawk
> >>>> release tasks (Although I don't think that the component will be
> useful[1]
> >>>> if it depends on JSF APIs only).
> >>>>
> >>>> A note about the commons project :
> >>>> I think we should have a clear vision or a draft plan that determines
> >>>> the project objectives, scope and road map.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> On Sun, Jun 8, 2008 at 5:16 PM, Volker Weber <[EMAIL PROTECTED]>
> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Can you create another exporterActionListener to include into comons
> >>>>> for non tomahawk users?
> >>>>> Or should i copy the pre 664385 svn version to commons?
> >>>>>
> >>>>>
> >>>>> Adding the complete tomahawk.jar just for this one tool is a no go,
> so
> >>>>> its worthless for me.
> >>>>>
> >>>>>
> >>>>> BTW should i add knowledge about the tobago sheet paging and start a
> >>>>> vote moving it to tobago?
> >>>>>
> >>>>> AFAIK the core of exporterActionListener is just based on jsf-api.
> >>>>> It is fine to have a version which 'knows' the library specific
> >>>>> extensions (t:dataScroller, tc:sheet, tr:table)
> >>>>> in the subprojects, but why  should we replicate the core exporter
> >>>>> sources instead of using/extending the
> >>>>> plain jsf-api version from commons?
> >>>>>
> >>>>> We should start putting useful stuff into commons or this subproject
> >>>>> will never grow.
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>>Volker
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2008/6/8 Hazem Saleh <[EMAIL PROTECTED]>:
> >>>>> > Hi Team,
> >>>>> >
> >>>>> > I just finished one of the improvements I intended to develop for
> the
> >>>>> > exporterActionListener component :
> >>>>> > * Integration with the Tomahawk dataScroller, so that it can be
> >>>>> > allowed for
> >>>>> > generating the only displayed dataTable page in the exported pdf or
> >>>>> > excel
> >>>>> > file.
> >>>>> >
> >>>>> > - Example of usage :
> >>>>> >
> >>>>> > 
> >>>>> >  >>>>> >  fileType="PDF" showDisplayedPageOnly="true"/>
> >>>>> > 
> >>>>> >
> >>>>> > As we see in the example, the component should know the Tomahawk
> >>>>> > scroller
> >>>>> > ID.
> >>>>> >

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

On Mon, Jun 9, 2008 at 3:00 PM, Volker Weber <[EMAIL PROTECTED]> wrote:

> Hi,
>
> 2008/6/8 Hazem Saleh <[EMAIL PROTECTED]>:
> > Hi Volker,
> >
> > I promise to do a separated one for commons after finishing my Tomahawk
> > release tasks (Although I don't think that the component will be useful
> if
> > it depends on JSF APIs only).
>
> >> i don't think, as i wrote before, code replication is reasonable here,
> >> why create a seperate if we already had one?
>
>
> >> In your commits, to add the  showDisplayedPageOnly attribute you have
> >> removed the ability to export a UIData content if it has no
> >> dataScroller attached.  Any reason why it should be nessesary to add a
> >> datascroller for exporting a 2 row table?
> *
> *because we want to have more features, IMHO this is the right way to go.
>
> >
> > A note about the commons project :
> > I think we should have a clear vision or a draft plan that determines the
> > project objectives, scope and road map.
>
> >> Except for the roadmap we have all this discussed, and imho cleared,
> >> months ago.

   Is there any document we can refer to ?
   Thanks!


>
>
>
> Regards,
> Volker
>
> >
> > Thanks!
> >
> > On Sun, Jun 8, 2008 at 5:16 PM, Volker Weber <[EMAIL PROTECTED]> wrote:
> >>
> >> Hi,
> >>
> >> Can you create another exporterActionListener to include into comons
> >> for non tomahawk users?
> >> Or should i copy the pre 664385 svn version to commons?
> >>
> >>
> >> Adding the complete tomahawk.jar just for this one tool is a no go, so
> >> its worthless for me.
> >>
> >>
> >> BTW should i add knowledge about the tobago sheet paging and start a
> >> vote moving it to tobago?
> >>
> >> AFAIK the core of exporterActionListener is just based on jsf-api.
> >> It is fine to have a version which 'knows' the library specific
> >> extensions (t:dataScroller, tc:sheet, tr:table)
> >> in the subprojects, but why  should we replicate the core exporter
> >> sources instead of using/extending the
> >> plain jsf-api version from commons?
> >>
> >> We should start putting useful stuff into commons or this subproject
> >> will never grow.
> >>
> >>
> >> Regards,
> >>Volker
> >>
> >>
> >>
> >>
> >> 2008/6/8 Hazem Saleh <[EMAIL PROTECTED]>:
> >> > Hi Team,
> >> >
> >> > I just finished one of the improvements I intended to develop for the
> >> > exporterActionListener component :
> >> > * Integration with the Tomahawk dataScroller, so that it can be
> allowed
> >> > for
> >> > generating the only displayed dataTable page in the exported pdf or
> >> > excel
> >> > file.
> >> >
> >> > - Example of usage :
> >> >
> >> > 
> >> >  >> >  fileType="PDF" showDisplayedPageOnly="true"/>
> >> > 
> >> >
> >> > As we see in the example, the component should know the Tomahawk
> >> > scroller
> >> > ID.
> >> > So I think it is not suitable to include this component in myfaces
> >> > commons
> >> > as it uses Tomahawk APIs.
> >> >
> >> > Let's resume voting again :
> >> > Now we have.
> >> > 3 votes for promoting the component to Tomahawk.
> >> > 2 votes for not promoting the component to Tomahawk and moving to
> >> > commons.
> >> >
> >> > Thanks all very much!
> >> >
> >> > On Fri, Jun 6, 2008 at 6:30 PM, Andrew Robinson
> >> > <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> Isn't Tomahawk already a commons set of components? It works with
> >> >> other render kits, besides some incompatibilities do to the filter
> >> >> design. I am wondering if we are attempting to put too much into
> >> >> commons.
> >> >>
> >> >> My take would be if this is a component that does any rendering it
> >> >> fits well in Tomahawk, but if it is more of a framework feature, then
> >> >> commons would be better.
> >> >>
> >> >> +0 for me though, I don't mind either approach, I'll let others
> decide.
> >> >>
> >> >

Re: [VOTE] promoting the exporterActionListener component to Tomahawk

[Hazem Saleh]

Hi Volker,

*I have many other features in my mind :*
1. In case of exporting all the whole report, the user can see the page
number at every page.
2. Adding the capability to export the data into more formats.
3. The ability of having a user actionMethod inside the exporter for
allowing (him/her) to create any content at the generated files.

To be in the middle, I can implement the following idea :
*We can make the following hierarchy :-*
BaseExporterListener (would be the old one, its tag will be
().
|
|--- TomahawkExporterListener (This would be the Tomahawk specific one) -->
().
|--- Other extensions...

What do you think about this idea ?

On Mon, Jun 9, 2008 at 4:58 PM, Volker Weber <[EMAIL PROTECTED]> wrote:

> Hi,
>
> 2008/6/9 Hazem Saleh <[EMAIL PROTECTED]>:
> >
> >
> > On Mon, Jun 9, 2008 at 3:00 PM, Volker Weber <[EMAIL PROTECTED]> wrote:
> >>
> >> Hi,
> >>
> >> 2008/6/8 Hazem Saleh <[EMAIL PROTECTED]>:
> >> > Hi Volker,
> >> >
> >> > I promise to do a separated one for commons after finishing my
> Tomahawk
> >> > release tasks (Although I don't think that the component will be
> useful
> >> > if
> >> > it depends on JSF APIs only).
> >>
> >> >> i don't think, as i wrote before, code replication is reasonable
> here,
> >> >> why create a seperate if we already had one?
> >>
> >>
> >> >> In your commits, to add the  showDisplayedPageOnly attribute you have
> >> >> removed the ability to export a UIData content if it has no
> >> >> dataScroller attached.  Any reason why it should be nessesary to add
> a
> >> >> datascroller for exporting a 2 row table?
> >>
> >> because we want to have more features, IMHO this is the right way to go.
>
>
> You can have more features without remove the ability to serve plain
> UIData, just do a
> if instance of on the for component.
>
> Can you explain which more features you have in mind?
> Paging is one we have in tomahawk, tobago and trinidad but i don't
> think we should dublicate
> the core code for exel/pdf generation into each of the libs.
>
> >>
> >> >
> >> > A note about the commons project :
> >> > I think we should have a clear vision or a draft plan that determines
> >> > the
> >> > project objectives, scope and road map.
> >>
> >> >> Except for the roadmap we have all this discussed, and imho cleared,
> >> >> months ago.
> >
> >Is there any document we can refer to ?
> >Thanks!
> >
>
> Not really, but most you can find here:
> http://www.nabble.com/-Proposal--Apache-MyFaces-commons-td10308101.html
>
> If you do a search for "myfaces commons" you will find a lot discussion
> threads.
>
>
> Regards,
> Volker
>
> >>
> >>
> >> Regards,
> >>Volker
> >>
> >> >
> >> > Thanks!
> >> >
> >> > On Sun, Jun 8, 2008 at 5:16 PM, Volker Weber <[EMAIL PROTECTED]>
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> Can you create another exporterActionListener to include into comons
> >> >> for non tomahawk users?
> >> >> Or should i copy the pre 664385 svn version to commons?
> >> >>
> >> >>
> >> >> Adding the complete tomahawk.jar just for this one tool is a no go,
> so
> >> >> its worthless for me.
> >> >>
> >> >>
> >> >> BTW should i add knowledge about the tobago sheet paging and start a
> >> >> vote moving it to tobago?
> >> >>
> >> >> AFAIK the core of exporterActionListener is just based on jsf-api.
> >> >> It is fine to have a version which 'knows' the library specific
> >> >> extensions (t:dataScroller, tc:sheet, tr:table)
> >> >> in the subprojects, but why  should we replicate the core exporter
> >> >> sources instead of using/extending the
> >> >> plain jsf-api version from commons?
> >> >>
> >> >> We should start putting useful stuff into commons or this subproject
> >> >> will never grow.
> >> >>
> >> >>
> >> >> Regards,
> >> >>Volker
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> 2008/6/8 Hazem Saleh <[EMAIL PROTEC

[VOTE] promoting the selectManyPicklist component to Tomahawk

[Hazem Saleh]

Hi Team,

After updating the selectManyPicklist documentation.

I wish to promote this selectManyPicklist (created by Bruno) to the next
Tomahawk release.

[+1] for agreeing with promoting the component to the next Tomahawk release.
[-1] for disagreeing with promoting the component to the next Tomahawk
release.


If there are any known issues, I can spend sometime at.

Thanks all very much!


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the selectManyPicklist component to Tomahawk

[Hazem Saleh]

+1.

On Mon, Jun 9, 2008 at 6:41 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> Hi Team,
>
> After updating the selectManyPicklist documentation.
>
> I wish to promote this selectManyPicklist (created by Bruno) to the next
> Tomahawk release.
>
> [+1] for agreeing with promoting the component to the next Tomahawk
> release.
> [-1] for disagreeing with promoting the component to the next Tomahawk
> release.
>
>
> If there are any known issues, I can spend sometime at.
>
> Thanks all very much!
>
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog




-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

[VOTE] promoting the subform component to Tomahawk

[Hazem Saleh]

Hi Team,

I wish to promote this subForm component to the next Tomahawk release.

[+1] for agreeing with promoting the component to the next Tomahawk release.
[-1] for disagreeing with promoting the component to the next Tomahawk
release.


Thanks all very much!

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the subform component to Tomahawk

[Hazem Saleh]

+1.

On Mon, Jun 9, 2008 at 6:54 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> Hi Team,
>
> I wish to promote this subForm component to the next Tomahawk release.
>
> [+1] for agreeing with promoting the component to the next Tomahawk
> release.
> [-1] for disagreeing with promoting the component to the next Tomahawk
> release.
>
>
> Thanks all very much!
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog




-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the subform component to Tomahawk

[Hazem Saleh]

Great, we have now 2 positive votes.

I will start promoting it after waiting another 24 hours.

On Mon, Jun 9, 2008 at 8:02 PM, Grant Smith <[EMAIL PROTECTED]> wrote:

> +1
>
>
> On Mon, Jun 9, 2008 at 8:56 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>
>> +1.
>>
>>
>> On Mon, Jun 9, 2008 at 6:54 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>>
>>> Hi Team,
>>>
>>> I wish to promote this subForm component to the next Tomahawk release.
>>>
>>> [+1] for agreeing with promoting the component to the next Tomahawk
>>> release.
>>> [-1] for disagreeing with promoting the component to the next Tomahawk
>>> release.
>>>
>>>
>>> Thanks all very much!
>>>
>>> --
>>> Hazem Ahmed Saleh Ahmed
>>> http://www.jroller.com/page/HazemBlog
>>
>>
>>
>>
>> --
>> Hazem Ahmed Saleh Ahmed
>> http://www.jroller.com/page/HazemBlog
>>
>
>
>
> --
> Grant Smith
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: svn commit messages

[Hazem Saleh]

Thank you guys for telling about this.
Iam always missing this.

On Tue, Jun 10, 2008 at 9:45 PM, simon <[EMAIL PROTECTED]> wrote:

>
> On Tue, 2008-06-10 at 18:32 +0200, Volker Weber wrote:
> > Hi Team,
> >
> > to those who commits just with the jira id as message:
> >Please add at least the jira title to the message.
> > I have no id was e.g MYFACES-1234 is, and no time to do always a jira
> lookup.
>
> +1
>
> Looking at commit emails, or svn history, it's really inconvenient to
> have to look up JIRA to get a clue about what the change did. And JIRA
> data is more likely to disappear in future than svn commit messages.
>
> >
> > An to those who don't adding a jira id:
> >   if you add the id we can track the related checkins in jira, so please
> do.
>
> +1 to this too.
>
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the subform component to Tomahawk

[Hazem Saleh]

Promotion is done :).

Now we can see :-

...


in Tomahawk :).

On Tue, Jun 10, 2008 at 1:09 PM, Manfred Geiler <[EMAIL PROTECTED]>
wrote:

> +1
>
> On Mon, Jun 9, 2008 at 5:54 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > Hi Team,
> >
> > I wish to promote this subForm component to the next Tomahawk release.
> >
> > [+1] for agreeing with promoting the component to the next Tomahawk
> release.
> > [-1] for disagreeing with promoting the component to the next Tomahawk
> > release.
> >
> >
> > Thanks all very much!
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>
> --
> http://www.irian.at
> Your JSF powerhouse - JSF Consulting,
> Development and Courses in English and
> German
>
> Professional Support for Apache MyFaces
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the subform component to Tomahawk

[Hazem Saleh]

Hi Volker,

Sorry for being so fast, I thought it is 48 hours :(.
I will read all the rules again.
Thanks very much!

On Wed, Jun 11, 2008 at 4:48 PM, Volker Weber <[EMAIL PROTECTED]> wrote:

> Hi Hazem,
>
> i think you are a bit to fast. You started the vote at 9. Juni 2008 17:54
> start committing the changes 44:20 hours:minutes (if i count correct)
> later at 11. Juni 2008 14:14.
>
> You should wait at least 72 Hours after starting the vote.
> See http://www.apache.org/foundation/voting.html.
>
> BTW:
> > Great, we have now 2 positive votes.
> >
> > I will start promoting it after waiting another 24 hours.
>
> You neet at last 3 positive votes, you got 4 in the meantime :-) .
>
>
>
> Regards,
>Volker
>
>
> 2008/6/11 Hazem Saleh <[EMAIL PROTECTED]>:
> > Promotion is done :).
> >
> > Now we can see :-
> > 
> > ...
> > 
> >
> > in Tomahawk :).
> >
> > On Tue, Jun 10, 2008 at 1:09 PM, Manfred Geiler <
> [EMAIL PROTECTED]>
> > wrote:
> >>
> >> +1
> >>
> >> On Mon, Jun 9, 2008 at 5:54 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> >> > Hi Team,
> >> >
> >> > I wish to promote this subForm component to the next Tomahawk release.
> >> >
> >> > [+1] for agreeing with promoting the component to the next Tomahawk
> >> > release.
> >> > [-1] for disagreeing with promoting the component to the next Tomahawk
> >> > release.
> >> >
> >> >
> >> > Thanks all very much!
> >> >
> >> > --
> >> > Hazem Ahmed Saleh Ahmed
> >> > http://www.jroller.com/page/HazemBlog
> >>
> >>
> >>
> >> --
> >> http://www.irian.at
> >> Your JSF powerhouse - JSF Consulting,
> >> Development and Courses in English and
> >> German
> >>
> >> Professional Support for Apache MyFaces
> >
> >
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>
> --
> inexso - information exchange solutions GmbH
> Bismarckstraße 13 | 26122 Oldenburg
> Tel.: +49 441 4082 356 |
> FAX: +49 441 4082 355 | www.inexso.de
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the selectManyPicklist component to Tomahawk

[Hazem Saleh]

Hi Team,

I still need a positive vote to be to start promoting this component
tomorrow.

On Tue, Jun 10, 2008 at 11:57 AM, Bruno Aranda <[EMAIL PROTECTED]>
wrote:

> +1
>
> 2008/6/9 Grant Smith <[EMAIL PROTECTED]>:
> > +0, Sorry I have not been able to find time to test this one yet.
> >
> > On Mon, Jun 9, 2008 at 8:41 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> >>
> >> +1.
> >>
> >> On Mon, Jun 9, 2008 at 6:41 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> >>>
> >>> Hi Team,
> >>>
> >>> After updating the selectManyPicklist documentation.
> >>>
> >>> I wish to promote this selectManyPicklist (created by Bruno) to the
> next
> >>> Tomahawk release.
> >>>
> >>> [+1] for agreeing with promoting the component to the next Tomahawk
> >>> release.
> >>> [-1] for disagreeing with promoting the component to the next Tomahawk
> >>> release.
> >>>
> >>>
> >>> If there are any known issues, I can spend sometime at.
> >>>
> >>> Thanks all very much!
> >>>
> >>>
> >>> --
> >>> Hazem Ahmed Saleh Ahmed
> >>> http://www.jroller.com/page/HazemBlog
> >>
> >>
> >> --
> >> Hazem Ahmed Saleh Ahmed
> >> http://www.jroller.com/page/HazemBlog
> >
> >
> > --
> > Grant Smith
> >
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the selectManyPicklist component to Tomahawk

[Hazem Saleh]

 component promotion is done :).

On Wed, Jun 11, 2008 at 11:01 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:

> +1
>
>
> On Wed, Jun 11, 2008 at 2:46 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>
>> Hi Team,
>>
>> I still need a positive vote to be to start promoting this component
>> tomorrow.
>>
>>
>> On Tue, Jun 10, 2008 at 11:57 AM, Bruno Aranda <[EMAIL PROTECTED]>
>> wrote:
>>
>>> +1
>>>
>>> 2008/6/9 Grant Smith <[EMAIL PROTECTED]>:
>>> > +0, Sorry I have not been able to find time to test this one yet.
>>> >
>>> > On Mon, Jun 9, 2008 at 8:41 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>>> >>
>>> >> +1.
>>> >>
>>> >> On Mon, Jun 9, 2008 at 6:41 PM, Hazem Saleh <[EMAIL PROTECTED]>
>>> wrote:
>>> >>>
>>> >>> Hi Team,
>>> >>>
>>> >>> After updating the selectManyPicklist documentation.
>>> >>>
>>> >>> I wish to promote this selectManyPicklist (created by Bruno) to the
>>> next
>>> >>> Tomahawk release.
>>> >>>
>>> >>> [+1] for agreeing with promoting the component to the next Tomahawk
>>> >>> release.
>>> >>> [-1] for disagreeing with promoting the component to the next
>>> Tomahawk
>>> >>> release.
>>> >>>
>>> >>>
>>> >>> If there are any known issues, I can spend sometime at.
>>> >>>
>>> >>> Thanks all very much!
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Hazem Ahmed Saleh Ahmed
>>> >>> http://www.jroller.com/page/HazemBlog
>>> >>
>>> >>
>>> >> --
>>> >> Hazem Ahmed Saleh Ahmed
>>> >> http://www.jroller.com/page/HazemBlog
>>> >
>>> >
>>> > --
>>> > Grant Smith
>>> >
>>>
>>
>>
>>
>> --
>> Hazem Ahmed Saleh Ahmed
>> http://www.jroller.com/page/HazemBlog
>>
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

[VOTE] promoting the selectOneRow component to Tomahawk

[Hazem Saleh]

Hi Team,

After updating the selectOneRow component's documentation.

I wish to promote it to the next Tomahawk release.

[+1] for agreeing with promoting the component to the next Tomahawk release.
[-1] for disagreeing with promoting the component to the next Tomahawk
release.

Thanks all very much!

-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the selectOneRow component to Tomahawk

[Hazem Saleh]

+1.

On Sun, Jun 15, 2008 at 4:16 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> Hi Team,
>
> After updating the selectOneRow component's documentation.
>
> I wish to promote it to the next Tomahawk release.
>
> [+1] for agreeing with promoting the component to the next Tomahawk
> release.
> [-1] for disagreeing with promoting the component to the next Tomahawk
> release.
>
> Thanks all very much!
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog




-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the selectOneRow component to Tomahawk

[Hazem Saleh]

+1 for Matzew idea.
I think that the old component syntax was suitable for the component when it
was in the sandbox phase.
I will implement this idea, it is good.
Thanks Matzew!

On Sun, Jun 15, 2008 at 11:16 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:

> On Sat, Jun 14, 2008 at 6:16 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > Hi Team,
> >
> > After updating the selectOneRow component's documentation.
>
> just curious, what is this component about?
> Using it like this ?
>
> 
>  
> 
>
> If so, how to declare multiple row selection ?
>
> Trinidad's table doesn't treat that as a special case. It just has an
> attribute for that, where you specify via an enum the selection type
> (single:mulit)
>
> Greetings,
> Matthias
>
> >
> > I wish to promote it to the next Tomahawk release.
> >
> > [+1] for agreeing with promoting the component to the next Tomahawk
> release.
> > [-1] for disagreeing with promoting the component to the next Tomahawk
> > release.
> >
> > Thanks all very much!
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the selectOneRow component to Tomahawk

[Hazem Saleh]

OK Let's make this as a vote :
we now have :
-> 2 votes for supporting the feature inside the t:dataTable.
-> 1 vote for leaving the current component as is.

On Sun, Jun 15, 2008 at 3:13 PM, simon <[EMAIL PROTECTED]> wrote:

> A separate component would be nice if it could be applied to any table,
> eg the h:dataTable.
>
> On Sun, 2008-06-15 at 13:40 +0300, Hazem Saleh wrote:
> > +1 for Matzew idea.
> > I think that the old component syntax was suitable for the component
> > when it was in the sandbox phase.
> > I will implement this idea, it is good.
> > Thanks Matzew!
> >
> > On Sun, Jun 15, 2008 at 11:16 AM, Matthias Wessendorf
> > <[EMAIL PROTECTED]> wrote:
> > On Sat, Jun 14, 2008 at 6:16 PM, Hazem Saleh
> > <[EMAIL PROTECTED]> wrote:
> > > Hi Team,
> > >
> > > After updating the selectOneRow component's documentation.
> >
> >
> > just curious, what is this component about?
> > Using it like this ?
> >
> > 
> >  
> > 
> >
> > If so, how to declare multiple row selection ?
> >
> > Trinidad's table doesn't treat that as a special case. It just
> > has an
> > attribute for that, where you specify via an enum the
> > selection type
> > (single:mulit)
> >
> > Greetings,
> > Matthias
> >
> >
> > >
> > > I wish to promote it to the next Tomahawk release.
> > >
> > > [+1] for agreeing with promoting the component to the next
> > Tomahawk release.
> > > [-1] for disagreeing with promoting the component to the
> > next Tomahawk
> > > release.
> > >
> > > Thanks all very much!
> > >
> > > --
> > > Hazem Ahmed Saleh Ahmed
> > > http://www.jroller.com/page/HazemBlog
> >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > mail: matzew-at-apache-dot-org
> >
> >
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the selectOneRow component to Tomahawk

[Hazem Saleh]

Any new votes ?

On Sun, Jun 15, 2008 at 4:13 PM, simon <[EMAIL PROTECTED]> wrote:

> I only suggested leaving it as it is *if* it is possible to use this
> component with tables other than t:dataTable.
>
> On Sun, 2008-06-15 at 15:57 +0300, Hazem Saleh wrote:
> > OK Let's make this as a vote :
> > we now have :
> > -> 2 votes for supporting the feature inside the t:dataTable.
> > -> 1 vote for leaving the current component as is.
> >
> > On Sun, Jun 15, 2008 at 3:13 PM, simon <[EMAIL PROTECTED]>
> > wrote:
> > A separate component would be nice if it could be applied to
> > any table,
> > eg the h:dataTable.
> >
> >
> > On Sun, 2008-06-15 at 13:40 +0300, Hazem Saleh wrote:
> > > +1 for Matzew idea.
> > > I think that the old component syntax was suitable for the
> > component
> > > when it was in the sandbox phase.
> > > I will implement this idea, it is good.
> > > Thanks Matzew!
> > >
> > > On Sun, Jun 15, 2008 at 11:16 AM, Matthias Wessendorf
> > > <[EMAIL PROTECTED]> wrote:
> > > On Sat, Jun 14, 2008 at 6:16 PM, Hazem Saleh
> > > <[EMAIL PROTECTED]> wrote:
> > > > Hi Team,
> > > >
> > > > After updating the selectOneRow component's
> > documentation.
> > >
> > >
> > > just curious, what is this component about?
> > > Using it like this ?
> > >
> > > 
> > >  
> > > 
> > >
> > > If so, how to declare multiple row selection ?
> > >
> > > Trinidad's table doesn't treat that as a special
> > case. It just
> > > has an
> > > attribute for that, where you specify via an enum
> > the
> > > selection type
> > > (single:mulit)
> > >
> > > Greetings,
> > > Matthias
> > >
> > >
> > > >
> > > > I wish to promote it to the next Tomahawk release.
> > > >
> > > > [+1] for agreeing with promoting the component to
> > the next
> > > Tomahawk release.
> > > > [-1] for disagreeing with promoting the component
> > to the
> > > next Tomahawk
> > > > release.
> > > >
> > > > Thanks all very much!
> > > >
> > > > --
> > > > Hazem Ahmed Saleh Ahmed
> > > > http://www.jroller.com/page/HazemBlog
> > >
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > mail: matzew-at-apache-dot-org
> > >
> > >
> > >
> > > --
> > > Hazem Ahmed Saleh Ahmed
> > > http://www.jroller.com/page/HazemBlog
> >
> >
> >
> >
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [VOTE] promoting the selectOneRow component to Tomahawk

[Hazem Saleh]

Hi Simon,

I will check this.

On Mon, Jun 16, 2008 at 10:04 AM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:

> I think it would be useful to have an answer to my question first.
>
> *Is* it possible to do this?
>  
>
>  
>
> If so, then moving from the current approach to using an attribute will
> remove existing functionality. Ok, with a sandbox component that is
> allowed but the above looks useful.
>
> Unfortunately I'm really busy on other things at the moment, and don't
> have time to look myself.
>
> Regards,
> Simon
>
> Hazem Saleh schrieb:
> > Any new votes ?
> >
> > On Sun, Jun 15, 2008 at 4:13 PM, simon <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > I only suggested leaving it as it is *if* it is possible to use this
> > component with tables other than t:dataTable.
> >
> > On Sun, 2008-06-15 at 15:57 +0300, Hazem Saleh wrote:
> > > OK Let's make this as a vote :
> > > we now have :
> > > -> 2 votes for supporting the feature inside the t:dataTable.
> > > -> 1 vote for leaving the current component as is.
> > >
> > > On Sun, Jun 15, 2008 at 3:13 PM, simon <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>>
> > > wrote:
> > > A separate component would be nice if it could be applied
> to
> > > any table,
> > > eg the h:dataTable.
> > >
> > >
> > > On Sun, 2008-06-15 at 13:40 +0300, Hazem Saleh wrote:
> > > > +1 for Matzew idea.
> > > > I think that the old component syntax was suitable for
> the
> > > component
> > > > when it was in the sandbox phase.
> > > > I will implement this idea, it is good.
> > > > Thanks Matzew!
> > > >
> > > > On Sun, Jun 15, 2008 at 11:16 AM, Matthias Wessendorf
> > > > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> > > > On Sat, Jun 14, 2008 at 6:16 PM, Hazem Saleh
> > > > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> > wrote:
> > > > > Hi Team,
> > > > >
> > > > > After updating the selectOneRow component's
> > > documentation.
> > > >
> > > >
> > > > just curious, what is this component about?
> > > > Using it like this ?
> > > >
> > > > 
> > > >  
> > > > 
> > > >
> > > > If so, how to declare multiple row selection ?
> > > >
> > > > Trinidad's table doesn't treat that as a special
> > > case. It just
> > > > has an
> > > > attribute for that, where you specify via an enum
> > > the
> > > > selection type
> > > > (single:mulit)
> > > >
> > > > Greetings,
> > > > Matthias
> > > >
> > > >
> > > > >
> > > > > I wish to promote it to the next Tomahawk
> > release.
> > > > >
> > > > > [+1] for agreeing with promoting the
> > component to
> > > the next
> > > > Tomahawk release.
> > > > > [-1] for disagreeing with promoting the
> > component
> > > to the
> > > > next Tomahawk
> > > > > release.
> >
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [myfaces commons] discussion about reorganization of this project is required!

[Hazem Saleh]

Leo,
I will start adding the base exporterListener to commons after your
refactoring.
Thanks.

On Tue, Jun 17, 2008 at 1:56 AM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:

> Hi
>
> I'll start to refactor myfaces-commons to the new proposed layout (I'm not
> started this yet because it was necessary check the actual state of
> converters and validators and solve some related issues):
>
> myfaces-commons-converters
> myfaces-commons-converters12
> myfaces-commons-validators
> myfaces-commons-validators12
> myfaces-commons-utils
>
> It could be good if we have also a:
>
> myfaces-commons-examples
>
> As a simple web app with all examples related to myfaces commons stuff
> (converters and validators). I is obvious to have this project, so I don't
> think this require a vote.
>
> The list of  components that should be moved to this location are this:
>
> mcc:convertBoolean
> mcc:convertDateTime
> mcc:convertNumber
> mcv:validateCompareTo
> mcv:validateCSV
> mcv:validateISBN
> mcv:validateUrl
> mcv:validateCreditCard
> mcv:validateEmail
> mcv:validateRegExpr
>
> validateEqual should be deprecated because validateCompareTo it is better
> (according to the suggestion of Mike), so this validator should stay on
> tomahawk. The rest of converters and validators only be referenced by
> tomahawk tld (so myfaces-commons becomes a tomahawk dependency).
>
> Suggestions are welcome
>
> regards
>
> Leonardo Uribe
>
> On Fri, Jun 13, 2008 at 9:24 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
> wrote:
>
>> On Fri, Jun 6, 2008 at 1:06 PM, Mike Kienenberger <[EMAIL PROTECTED]>
>> wrote:
>> > I'd recommend not migrating t:validateEqual across to myfaces-commons.
>> >  t:validateEquals is a special case of t:validateCompareTo, and, if I
>> > recall correctly, the code in validateEquals is not as flexible as the
>> > code in validateCompareTo.   There's no point in maintaining the
>> > inferior limited version in the reorganization.
>>
>> +1
>>
>> >
>> > On 6/6/08, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Jun 6, 2008 at 8:54 AM, Paul Spencer <[EMAIL PROTECTED]>
>> wrote:
>> >> > Leonardo Uribe wrote:
>> >> >
>> >> > >
>> >> > > Hi
>> >> > >
>> >> > > I'll start to upgrade component from sandbox to tomahawk.
>> >> > >
>> >> > > The first item on my list of todos is move this converters and
>> >> validators
>> >> > > (first check and solve possible issues on JIRA)
>> >> > >
>> >> > > s:convertBoolean
>> >> > > s:convertDateTime
>> >> > > s:convertNumber
>> >> > > s:validateCompareTo
>> >> > > s:validateCSV
>> >> > > s:validateISBN
>> >> > > s:validateUrl
>> >> > >
>> >> > > Please note that long time ago this upgrade was approved, but this
>> was
>> >> not
>> >> > > applied due to code generation discussion.
>> >> > >
>> >>
>> 
>> >> > >
>> >> > >
>> >> > > Actually on tomahawk exists this validators:
>> >> > >
>> >> > > t:validateCreditCard
>> >> > > t:validateEmail
>> >> > > t:validateEqual
>> >> > > t:validateRegExpr
>> >> > >
>> >> > > The idea is that all this converters and validators be on
>> >> myfaces-commons.
>> >> > > But originally tomahawk is 1.1 compatible, and there was comments
>> about
>> >> > > commons should have 1.1  and 1.2 converters and validators. If this
>> is
>> >> true,
>> >> > > tomahawk should refer myfaces commons converters and validators on
>> its
>> >> tld,
>> >> > > and have dependecies to commons (if false this is valid only for
>> 1.2).
>> >> > >
>> >> > >
>> >> >
>> >> > +1 for true. The thought of maintaining 2 sets of converts/valdiators
>> is
>> >> unnerving.
>> >> >
>> >> >
>> >> >
>> >> > > The new unpack plugin allow us to manage this issues more easily,
>> >> enforcing
>> >> > > just the necessary files to maintain.
>> >> > >
>> >> > > In order to be consistent with this intentions my first approach
>> would
>> >> be:
>> >> > >
>> >> > > 1. Use this layout for myfaces-commons:
>> >> > >
>> >> > > myfaces-commons-converters
>> >> > > myfaces-commons-converters12
>> >> > > myfaces-commons-validators
>> >> > > myfaces-commons-validators12
>> >> > > myfaces-commons-utils
>> >> > >
>> >> > > 2. Use myfaces-builder-plugin for this stuff.
>> >> > >
>> >> > > 3. Refer converters and validator from commons to tomahawk tld (the
>> >> > > intention is avoid changes on existing applications).
>> >> > >
>> >> > >
>> >> > I suggest deprecating the existing converters/validators.
>> >> >
>> >>
>> >> Good idea but needs some concensus about this. Deprecate means do not
>> >> exclude it but refer the users to myfaces commons.
>> >>
>> >> >
>> >> >
>> >> > > Suggestions are welcome
>> >> > >
>> >> > >
>> >> >
>> >> > o What is the impact on the other components, i.e.
>> Trinidad/Tobago/...?
>> >> >
>> >>
>> >> no impact, myfaces commons does not have any release yet and does not
>> have
>> >> dependencies with anything (the idea of this discussion is organize
>> this
>> >> stuff and make a release of this!).
>> >>
>> >> >
>> >> > o Is this to be included in Tomahawk 1.1.7?
>> >

Re: [myfaces commons] discussion about reorganization of this project is required!

[Hazem Saleh]

+1 for adding examples.

On Tue, Jun 17, 2008 at 1:12 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> Leo,
> I will start adding the base exporterListener to commons after your
> refactoring.
> Thanks.
>
>
> On Tue, Jun 17, 2008 at 1:56 AM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
>
>> Hi
>>
>> I'll start to refactor myfaces-commons to the new proposed layout (I'm not
>> started this yet because it was necessary check the actual state of
>> converters and validators and solve some related issues):
>>
>> myfaces-commons-converters
>> myfaces-commons-converters12
>> myfaces-commons-validators
>> myfaces-commons-validators12
>> myfaces-commons-utils
>>
>> It could be good if we have also a:
>>
>> myfaces-commons-examples
>>
>> As a simple web app with all examples related to myfaces commons stuff
>> (converters and validators). I is obvious to have this project, so I don't
>> think this require a vote.
>>
>> The list of  components that should be moved to this location are this:
>>
>> mcc:convertBoolean
>> mcc:convertDateTime
>> mcc:convertNumber
>> mcv:validateCompareTo
>> mcv:validateCSV
>> mcv:validateISBN
>> mcv:validateUrl
>> mcv:validateCreditCard
>> mcv:validateEmail
>> mcv:validateRegExpr
>>
>> validateEqual should be deprecated because validateCompareTo it is better
>> (according to the suggestion of Mike), so this validator should stay on
>> tomahawk. The rest of converters and validators only be referenced by
>> tomahawk tld (so myfaces-commons becomes a tomahawk dependency).
>>
>> Suggestions are welcome
>>
>> regards
>>
>> Leonardo Uribe
>>
>> On Fri, Jun 13, 2008 at 9:24 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
>> wrote:
>>
>>> On Fri, Jun 6, 2008 at 1:06 PM, Mike Kienenberger <[EMAIL PROTECTED]>
>>> wrote:
>>> > I'd recommend not migrating t:validateEqual across to myfaces-commons.
>>> >  t:validateEquals is a special case of t:validateCompareTo, and, if I
>>> > recall correctly, the code in validateEquals is not as flexible as the
>>> > code in validateCompareTo.   There's no point in maintaining the
>>> > inferior limited version in the reorganization.
>>>
>>> +1
>>>
>>> >
>>> > On 6/6/08, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Jun 6, 2008 at 8:54 AM, Paul Spencer <[EMAIL PROTECTED]>
>>> wrote:
>>> >> > Leonardo Uribe wrote:
>>> >> >
>>> >> > >
>>> >> > > Hi
>>> >> > >
>>> >> > > I'll start to upgrade component from sandbox to tomahawk.
>>> >> > >
>>> >> > > The first item on my list of todos is move this converters and
>>> >> validators
>>> >> > > (first check and solve possible issues on JIRA)
>>> >> > >
>>> >> > > s:convertBoolean
>>> >> > > s:convertDateTime
>>> >> > > s:convertNumber
>>> >> > > s:validateCompareTo
>>> >> > > s:validateCSV
>>> >> > > s:validateISBN
>>> >> > > s:validateUrl
>>> >> > >
>>> >> > > Please note that long time ago this upgrade was approved, but this
>>> was
>>> >> not
>>> >> > > applied due to code generation discussion.
>>> >> > >
>>> >>
>>> 
>>> >> > >
>>> >> > >
>>> >> > > Actually on tomahawk exists this validators:
>>> >> > >
>>> >> > > t:validateCreditCard
>>> >> > > t:validateEmail
>>> >> > > t:validateEqual
>>> >> > > t:validateRegExpr
>>> >> > >
>>> >> > > The idea is that all this converters and validators be on
>>> >> myfaces-commons.
>>> >> > > But originally tomahawk is 1.1 compatible, and there was comments
>>> about
>>> >> > > commons should have 1.1  and 1.2 converters and validators. If
>>> this is
>>> >> true,
>>> >> > > tomahawk should refer myfaces commons converters and validators on
>>> its
>>>