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,
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
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
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
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
Others can correct me if I'm wrong but I think the votes should be
binding. I think this means it is PMC's and commiters and a
descending vote ( called a veto) blocks it.
On Jun 9, 2008, at 6:45 AM, Hazem Saleh [EMAIL PROTECTED] wrote:
Hi Volker,
I think we should take the whole votes,
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)
Hi Hazem,
2008/6/9 Hazem Saleh [EMAIL PROTECTED]:
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
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
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
[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
+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
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 :*
Hi Hazem,
the question is if the exporterActionListener component currently
depends on tomahawk.
if this is not the case i'm against moving it into tomahawk.
A future tomahawk specific version could extend the commons version of
this component.
There is no problem if tomahwk depends on commons
Hi Leonardo,
the commons project is not only for validators and converterts,
but for all kind of renderkit independent jsf (tools/utils/...).
the missing of a suitable commons submodule could not be a reason.
imho a commons-tools could be a possible module for the
exporterActionListener
On Fri, Jun 6, 2008 at 10:03 AM, Volker Weber [EMAIL PROTECTED] wrote:
Hi Hazem,
the question is if the exporterActionListener component currently
depends on tomahawk.
if this is not the case i'm against moving it into tomahawk.
+1
A future tomahawk specific version could extend the
On Fri, Jun 6, 2008 at 10:10 AM, Volker Weber [EMAIL PROTECTED] wrote:
Hi Leonardo,
the commons project is not only for validators and converterts,
but for all kind of renderkit independent jsf (tools/utils/...).
yup. I don't know why we always have to clarify that...
To me this is clear ;-)
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
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:
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
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
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
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
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,
+1
Hazem Saleh schrieb:
+1
On Thu, Jun 5, 2008 at 4:45 PM, Hazem Saleh [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi Team,
After integration the pdfExport and the excelExport components into
the exporterActionListener component,
improving its syntax and completing
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
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]
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
28 matches
Mail list logo
