HTML5 Project
Hi, I think it is now a good time to drop/stop the HTML5 project. In the past months, we couldn't make a release or even decide what would be the future of the project. I won't be working on the project anymore, because I am focused on other things. Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [html5] alpha release for myfaces html5
One important point is labs projects are not allowed to make releases.
Sent from Android
On Nov 2, 2011 1:22 PM, Gerhard Petracek gerhard.petra...@gmail.com
wrote:
see [1] - esp.:
Apache Labs are the place where ASF committers can work on innovative,
blue-sky and off-the-wall ideas, without having to worry about fitting in
an existing project bylaw or building a community around it...
we already know that it works and it's just about a community check
- imo labs doesn't fit and the alternative would be the incubator
itself.
regards,
gerhard
[1] http://labs.apache.org/bylaws.html
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/11/2 Matthias Wessendorf mat...@apache.org:
I don't get why not just having a simple alpha release ?
Does not hurt... Or... move the entire thing to Apache Labs... for
future experiments ?!
-M
On Tue, Nov 1, 2011 at 12:03 AM, Ali Ok al...@aliok.com.tr wrote:
Hi,
So do you think myfaces/incubator/html5 is a good place?
Greetings,
Ali
On Sat, Oct 22, 2011 at 1:37 PM, Ali Ok al...@aliok.com.tr wrote:
Hi,
In my opinion as long this lib is html5 only it should not be part of
the tomahawk project
I agree, no relation with Tomahawk.
a different idea would be a small myfaces-incubator for new
project-ideas
(esp. for gsoc projects).
Makes more sense to me than Tomahawk.
I think (almost) everyone is in favor of moving the project to
somewhere
else, I am also ok with it.
Important thing for the project is having the ability for releases and
the
jars are deployed to maven repo.
Cheers,
Ali
On Sat, Oct 22, 2011 at 11:05 AM, Mark Struberg strub...@yahoo.de
wrote:
including our very own little 'attic' :)
Actually the big difference between the incubator and a mf subproject
would be the IP clearance. We really need to do this upfront before
importing.
But actually I like this much more than having projects developed
outside
and only later brought into our SVN - because this causes lots of
paperwork
(gas grants and a IP clearance review is mandatory).
Thus a +1
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Saturday, October 22, 2011 10:58 AM
Subject: Re: [html5] alpha release for myfaces html5
a different idea would be a small myfaces-incubator for new
project-ideas (esp. for gsoc projects).
we can release parts easily and drop them if we see that something
doesn't work for our community. if an idea works for the community,
we can
discuss the correct place for it.
we might see new gsoc projects (related to myfaces) every year. imo
it's
the wrong approach to just add them as new sub-project and we don't
have the
resources/community to maintain them.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Bernd Bohmann bernd.bohm...@atanion.com
Ha, I don't think we should wait for the jsf-eg.
Hey guys they are asking for a alpha release.
In my opinion as long this lib is html5 only it should not be part
of
the tomahawk project.
I don't see any problems in releasing an alpha release. But before a
beta we should decide own extension or tomahawk.
Regards
Bernd
On Sat, Oct 22, 2011 at 9:31 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
it's planned that jsf2.2 will get some sort of html5 support.
imo we should work together with the jsf-eg to ensure that we
won't
promote
incompatible components.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Mark Struberg strub...@yahoo.de
+1 for moving it to tomahawk.
One big open question for me is our html5 strategy at all.
Will the html5 components provide legacy html support themselfs?
Thus a calendar component will use jQuery (or whatever) calendar
when a
non-html5 browser is detected,
or is this in the responsibility of the developer?
if (html5){
} else{
//fallback
}
?
Afaik our current html5 components 'only' support pure html5
rendering,
isn't?
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Friday, October 21, 2011 10:22 PM
Subject: Re: [html5] alpha release for myfaces html5
@grant: +1
regards,
gerhard
http://www.irian.at
Your JSF
Re: [html5] alpha release for myfaces html5
Hi,
So do you think myfaces/incubator/html5 is a good place?
Greetings,
Ali
On Sat, Oct 22, 2011 at 1:37 PM, Ali Ok al...@aliok.com.tr wrote:
Hi,
In my opinion as long this lib is html5 only it should not be part of
the tomahawk project
I agree, no relation with Tomahawk.
a different idea would be a small myfaces-incubator for new project-ideas
(esp. for gsoc projects).
Makes more sense to me than Tomahawk.
I think (almost) everyone is in favor of moving the project to somewhere
else, I am also ok with it.
Important thing for the project is having the ability for releases and the
jars are deployed to maven repo.
Cheers,
Ali
On Sat, Oct 22, 2011 at 11:05 AM, Mark Struberg strub...@yahoo.de wrote:
including our very own little 'attic' :)
Actually the big difference between the incubator and a mf subproject
would be the IP clearance. We really need to do this upfront before
importing.
But actually I like this much more than having projects developed outside
and only later brought into our SVN - because this causes lots of paperwork
(gas grants and a IP clearance review is mandatory).
Thus a +1
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Saturday, October 22, 2011 10:58 AM
Subject: Re: [html5] alpha release for myfaces html5
a different idea would be a small myfaces-incubator for new
project-ideas (esp. for gsoc projects).
we can release parts easily and drop them if we see that something
doesn't work for our community. if an idea works for the community, we can
discuss the correct place for it.
we might see new gsoc projects (related to myfaces) every year. imo it's
the wrong approach to just add them as new sub-project and we don't have
the resources/community to maintain them.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Bernd Bohmann bernd.bohm...@atanion.com
Ha, I don't think we should wait for the jsf-eg.
Hey guys they are asking for a alpha release.
In my opinion as long this lib is html5 only it should not be part of
the tomahawk project.
I don't see any problems in releasing an alpha release. But before a
beta we should decide own extension or tomahawk.
Regards
Bernd
On Sat, Oct 22, 2011 at 9:31 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
it's planned that jsf2.2 will get some sort of html5 support.
imo we should work together with the jsf-eg to ensure that we won't
promote
incompatible components.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Mark Struberg strub...@yahoo.de
+1 for moving it to tomahawk.
One big open question for me is our html5 strategy at all.
Will the html5 components provide legacy html support themselfs?
Thus a calendar component will use jQuery (or whatever) calendar
when a
non-html5 browser is detected,
or is this in the responsibility of the developer?
if (html5){
} else{
//fallback
}
?
Afaik our current html5 components 'only' support pure html5
rendering,
isn't?
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Friday, October 21, 2011 10:22 PM
Subject: Re: [html5] alpha release for myfaces html5
@grant: +1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Grant Smith work.gr...@gmail.com
I must agree with Gerhard. The whole point of the sandbox is for
this
very purpose. However, perhaps we should look at the sandbox more
often and
vote on components that are ready to graduate.
On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi leo,
imo such an argument doesn't justify an own sub-project. i
don't say
-1. my point is that we should discuss it (esp. because the
situation
changed).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Leonardo Uribe lu4...@gmail.com
Hi
The problem with move to tomahawk sandbox is those artifact can't
never be released. Do an alpha release give us the chance to
know if
the bits are good enough, get more feedback, and later decide
what to
do. The truth is some people only test some artifacts after a
release. Do it as an alpha
Re: [html5] alpha release for myfaces html5
, Leonardo Uribe 2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com: hi ali, most commits happened directly after the initial import. that didn't look very promising. it's great to hear that you plan to continue. however, since we haven't seen a lot of activity, we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Ali Ok al...@aliok.com.tr Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com: before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC. -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [html5] alpha release for myfaces html5
Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petracek@**gmail.comgerhard.petra...@gmail.com : before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/**html5/ http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [html5] alpha release for myfaces html5
Hi, The truth is some people only test some artifacts after a release. Do it as an alpha release means ... software that has just been compiled and ready for its initial test inhouse. Yes, exactly. Everyone is using maven, and even I am annoyed when I try to use this library in another machine for the first time, since there is no repo for maven to download it. IMHO, having release cycles for the project would be really great. I also know the project needs more effort, but first thing we need is feedback. we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). If you think this way is better for the project, then IMHO it is also OK. I think this would be an advantage for the project if more people are going to participate. But what are the advantages of moving into sandbox? Or, I should ask, what are the concerns with the current way? If we clear this, we can easily decide :) Cheers, Ali On Fri, Oct 21, 2011 at 10:22 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: @grant: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Grant Smith work.gr...@gmail.com I must agree with Gerhard. The whole point of the sandbox is for this very purpose. However, perhaps we should look at the sandbox more often and vote on components that are ready to graduate. On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi leo, imo such an argument doesn't justify an own sub-project. i don't say -1. my point is that we should discuss it (esp. because the situation changed). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribe lu4...@gmail.com Hi The problem with move to tomahawk sandbox is those artifact can't never be released. Do an alpha release give us the chance to know if the bits are good enough, get more feedback, and later decide what to do. The truth is some people only test some artifacts after a release. Do it as an alpha release means ... software that has just been compiled and ready for its initial test inhouse. I think that is enough clear. regards, Leonardo Uribe 2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com: hi ali, most commits happened directly after the initial import. that didn't look very promising. it's great to hear that you plan to continue. however, since we haven't seen a lot of activity, we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Ali Ok al...@aliok.com.tr Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com: before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do
[jira] [Created] (MFHTML5-16) Slide component is not working with swipes on touchscreen devices
Slide component is not working with swipes on touchscreen devices - Key: MFHTML5-16 URL: https://issues.apache.org/jira/browse/MFHTML5-16 Project: MyFaces HTML5 Component Library Issue Type: Bug Components: Component Library Affects Versions: 1.0.0-alpha-SNAPSHOT Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-17) Add next buttons on the slides for the devices not supporting swipes, mousewheel, or key press
Add next buttons on the slides for the devices not supporting swipes, mousewheel, or key press Key: MFHTML5-17 URL: https://issues.apache.org/jira/browse/MFHTML5-17 Project: MyFaces HTML5 Component Library Issue Type: Improvement Components: Demo Affects Versions: 1.0.0-alpha-SNAPSHOT Reporter: Ali Ok -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-15) Create Html5 notifications component(s)
Create Html5 notifications component(s) --- Key: MFHTML5-15 URL: https://issues.apache.org/jira/browse/MFHTML5-15 Project: MyFaces HTML5 Component Library Issue Type: New Feature Components: Component Library Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MFHTML5-5) Update the apt docs
[ https://issues.apache.org/jira/browse/MFHTML5-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali Ok resolved MFHTML5-5. -- Resolution: Fixed Update the apt docs --- Key: MFHTML5-5 URL: https://issues.apache.org/jira/browse/MFHTML5-5 Project: MyFaces HTML5 Component Library Issue Type: Bug Reporter: Ali Ok Assignee: Ali Ok Fix For: 1.0.0-alpha-SNAPSHOT -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MFHTML5-2) Delete myfaces-shared-html5 project
[ https://issues.apache.org/jira/browse/MFHTML5-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali Ok resolved MFHTML5-2. -- Resolution: Fixed It seems I've already deleted that project. Dependencies are now deleted. Delete myfaces-shared-html5 project --- Key: MFHTML5-2 URL: https://issues.apache.org/jira/browse/MFHTML5-2 Project: MyFaces HTML5 Component Library Issue Type: Task Components: Component Library Affects Versions: 1.0.0-alpha-SNAPSHOT Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-13) Create Hudson build plans
Create Hudson build plans - Key: MFHTML5-13 URL: https://issues.apache.org/jira/browse/MFHTML5-13 Project: MyFaces HTML5 Component Library Issue Type: Task Components: Component Library, Demo Affects Versions: 1.0.0-beta1 Reporter: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MFHTML5-7) Make the project Mojarra compatible
[ https://issues.apache.org/jira/browse/MFHTML5-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092881#comment-13092881 ] Ali Ok commented on MFHTML5-7: -- Need to update the documentation to state that the comp. lib. is compatible with any JSF impl. Make the project Mojarra compatible --- Key: MFHTML5-7 URL: https://issues.apache.org/jira/browse/MFHTML5-7 Project: MyFaces HTML5 Component Library Issue Type: Improvement Components: Component Library Reporter: Ali Ok Fix For: 1.0.0-beta1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MFHTML5-6) Add some tests that check if the passthrough properties are rendered correctly
[ https://issues.apache.org/jira/browse/MFHTML5-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali Ok resolved MFHTML5-6. -- Resolution: Fixed Fix Version/s: 1.0.0-alpha-SNAPSHOT Add some tests that check if the passthrough properties are rendered correctly -- Key: MFHTML5-6 URL: https://issues.apache.org/jira/browse/MFHTML5-6 Project: MyFaces HTML5 Component Library Issue Type: Task Reporter: Ali Ok Assignee: Ali Ok Fix For: 1.0.0-alpha-SNAPSHOT -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-8) Find a way to display the source for demo pages
Find a way to display the source for demo pages --- Key: MFHTML5-8 URL: https://issues.apache.org/jira/browse/MFHTML5-8 Project: MyFaces HTML5 Component Library Issue Type: New Feature Components: Demo Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-9) Display the source of demo pages with a keyboard shortcut
Display the source of demo pages with a keyboard shortcut - Key: MFHTML5-9 URL: https://issues.apache.org/jira/browse/MFHTML5-9 Project: MyFaces HTML5 Component Library Issue Type: New Feature Components: Demo Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-7) Make the project Mojarra compatible
Make the project Mojarra compatible --- Key: MFHTML5-7 URL: https://issues.apache.org/jira/browse/MFHTML5-7 Project: MyFaces HTML5 Component Library Issue Type: Improvement Components: Component Library Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-10) URL hashing support for slide view
URL hashing support for slide view -- Key: MFHTML5-10 URL: https://issues.apache.org/jira/browse/MFHTML5-10 Project: MyFaces HTML5 Component Library Issue Type: New Feature Components: Component Library Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-11) Wrapper for steelseries library
Wrapper for steelseries library --- Key: MFHTML5-11 URL: https://issues.apache.org/jira/browse/MFHTML5-11 Project: MyFaces HTML5 Component Library Issue Type: New Feature Components: Component Library Reporter: Ali Ok Assignee: Ali Ok The author of steel series library already got rid of some GPL dependencies for wrapping them within MFHTML5. - Radial gauge - RadialBargraph gauge - Linear gauge - LinearBargraph gauge - Compass component - Level component - LED component -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-12) Get rid of JSP tag generation for components and others
Get rid of JSP tag generation for components and others --- Key: MFHTML5-12 URL: https://issues.apache.org/jira/browse/MFHTML5-12 Project: MyFaces HTML5 Component Library Issue Type: Improvement Components: Component Library Reporter: Ali Ok Currently, the Myfaces builder plugin is configured that way. We'd better remove the generation of JSP tags. I think for a new project it is fair to say that support for JSP does not exist. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: MyFaces Html5 - Help request for release
Hi Leo, Thanks for all your work. I will let the group know when I am done with writing tests. Cheers, Ali On Tue, May 24, 2011 at 7:42 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Leo, Great news! Regards, Jakob 2011/5/24 Leonardo Uribe lu4...@gmail.com: Hi I have deployed the site for html5 project: http://myfaces.apache.org/html5 and the initial configuration for release it using nexus is complete. In this point, we can run a release procedure, but I would like to have some junit tests for the components first. Note since this is an alpha release it is not really necessary to have those tests before release. regards, Leonardo Uribe -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[jira] [Created] (MFHTML5-6) Add some tests that check if the passthrough properties are rendered correctly
Add some tests that check if the passthrough properties are rendered correctly -- Key: MFHTML5-6 URL: https://issues.apache.org/jira/browse/MFHTML5-6 Project: MyFaces HTML5 Component Library Issue Type: Task Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-5) Update the apt docs
Update the apt docs --- Key: MFHTML5-5 URL: https://issues.apache.org/jira/browse/MFHTML5-5 Project: MyFaces HTML5 Component Library Issue Type: Bug Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [myfaces] ideas and things to do
Hi, @HTML5 Release this stuff in the near future give us the advantage to know which things are required to include on the spec to support it fully. I don't see any technical reason why this couldn't be done, and given the code available and the effort required I think it is worth to do it. +1 Would be cool to provide HTML5 stuff if platform supports it and provide graceful degradation for legacy(IE) Cagatay, I see you do it in PrimeFaces successfully, which is great. In PrimeFaces you can freely include other open source libraries which do the degradation for IE and legacy browsers. However that is kind of hard in Myfaces because of the ASF and ASL policy. I remember, once I couldn't find a reasonable flash video player whose license is compatible with ASL. I tried to use one for automatic degradation, then I decided to provide a way for component library users to define their fallback. So, we have to write all of those stuff by ourselves which is really hard, or bundle them outside ASF and use them the other way. I say writing them are really hard, since writing that kind of JS for IE and legacy browsers, which either ignore the standards or interpret them wrong, are painful. From my point of view, current effort of Html5 support is useful for the future and it is great to have a know-how about JSF+Html5 integration. Of course that doesn't mean current codebase is not to be used in production. Cheers, Ali On Tue, May 17, 2011 at 7:55 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Totally agreed, Leo! Regards, Jakob 2011/5/17 Leonardo Uribe lu4...@gmail.com: Hi @HTML5 Release this stuff in the near future give us the advantage to know which things are required to include on the spec to support it fully. I don't see any technical reason why this couldn't be done, and given the code available and the effort required I think it is worth to do it. @Advanced ResourceHandler: It is good to know there is some effort to include this into the spec. But I think our position related to changes or enhancements to do should be if there is no technical reason that prevent us to include it in a module or even inside myfaces core, the way to go is just do it now and later if the EG is willing to include it, well, we can help with that. In the two previous cases this advice applies. It is important that myfaces can be seen as a source of innovation in jsf and develop these ideas goes into that direction. Additionally, this helps to the spec to move more faster and that's good for everybody. Leonardo 2011/5/17 Jakob Korherr jakob.korh...@gmail.com: Hi, @HTML5 I think a first alpha release of Ali's project would be very good to have in the near future @Advanced ResourceHandler: Of course there should be some additional work in the JSF EG, but I think Jakob pinged Ed already on this topic, right? Yeap, we (the JSF 2.2 EG) are/will be working on it, see JAVASERVERFACES_SPEC_PUBLIC-947 The commons-resourcehandler module currently is a prototype for the new JSF 2.2 resource handler. It has the advantage that JSF 2.0 apps (even those running on Mojarra) can already use it (but more on that in the other mail). @JSF 2.2 prototyping branch: +++1! I'd like to have a branch for the resource-handler work! Regards, Jakob 2011/5/17 Cagatay Civici cagatay.civ...@gmail.com: There is still no really lightweight component framework for JSF-2. I disagree :) The HTML-5 components from Ali are really great stuff too, but might take some time to be widely supported. But anyway, being a step ahead is always a good thing! Ali's work is great but why brand it as HTML5? JSF is widely used in corporates which depend on IE so branding it as HTML5 might have a negative effect on adoption. Would be cool to provide HTML5 stuff if platform supports it and provide graceful degradation for legacy(IE). For example in PrimeFaces I try to integrate HTML5 stuff like fileupload, charts(canvas) with this way under the hood. A component framework with HTML5 features sound better to me instead of just HTML5 components. On May 17, 2011, at 2:34 PM, Martin Koci wrote: Gerhard Petracek píše v Út 17. 05. 2011 v 11:59 +0200: hi, imo we should prototype some jsf 2.2 features (at least in a branch). that would help the eg to specify some of the new features (like the window-id) easily and we can get the feedback of the whole community and we would have the basic implementation quite early. so we increase the chance that the new features won't have to be deprecated in the next version (see the target attribute of composite-components). 1 ! JSF need feedback from real usage before features are specified (as final), not after. Only that way leads to framework with real useability. since html5 is planned as a part of jsf 2.2,
Re: MyFaces Html5 - Help request for release
Hi, Thanks Leo and Jakob for your help. The first thing we need to do is create a site module for this project. I tried doing that once. There are some apt files already. mvn clean install site -P generate-site (yes, install or sth else is also necessary) generates the site. It is a little bit outdated, but I will update them in the mean time. I also couldn't make the module sites integrated into parent, which is done while releasing if I remember correctly. I think it could be good to add some testing code like the one in tomahawk, that checks automatically if the passthrough properties are rendered correctly. Ok, I hope I can find time for that before you work on the configuration. Thanks, Ali On Tue, May 17, 2011 at 1:09 AM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Ali, Leo, If you guys need any help, just ping me ;) Regards, Jakob 2011/5/16 Leonardo Uribe lu4...@gmail.com: Hi Ali I can help you with the release stuff. The first thing we need to do is create a site module for this project. Right now I'm busy doing some enhancements for tomahawk sandbox (new components, new example module with myfaces skin, like codi examples) and tomorrow a vote for release myfaces-test will be sent. So I'll check html5 project and do the necessary configuration at the end of this week. I think it could be good to add some testing code like the one in tomahawk, that checks automatically if the passthrough properties are rendered correctly. regards, Leonardo Uribe 2011/5/16 Ali Ok al...@aliok.com.tr: Hi all, I finally found some time for fixing the final known-issues. I think, as we talked before [1], we can proceed with an alpha release. Can someone help me in this subject? I am kind of lost in code-signing, ASF rules, etc. Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
MyFaces Html5 - Help request for release
Hi all, I finally found some time for fixing the final known-issues. I think, as we talked before [1], we can proceed with an alpha release. Can someone help me in this subject? I am kind of lost in code-signing, ASF rules, etc. Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[jira] [Resolved] (MFHTML5-1) Get rid of myfaces-shared-html5 dependency
[ https://issues.apache.org/jira/browse/MFHTML5-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali Ok resolved MFHTML5-1. -- Resolution: Fixed Get rid of myfaces-shared-html5 dependency -- Key: MFHTML5-1 URL: https://issues.apache.org/jira/browse/MFHTML5-1 Project: MyFaces HTML5 Component Library Issue Type: Improvement Components: Component Library Affects Versions: 1.0.0-alpha-SNAPSHOT Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Html5 Component Library - Alpha Release
Hi, Can you show me a project that uses common-utils20? I couldn't find any. I will try to figure out usage of some functionality. For example why constants in http://myfaces.apache.org/commons20/myfaces-commons-utils20/apidocs/org/apache/myfaces/commons/util/renderkit/HTML.html are not static and etc. Thanks, Ali On Mon, Mar 21, 2011 at 12:58 AM, Ali Ok al...@aliok.com.tr wrote: Hi, From this point of view, instead create a shared html5 module, we should check which code is used by its renderers and create the files necessary on myfaces-commons-utils that provides those utility methods. Note it is not a copy of shared, some methods could have changes in its signature or could be located in other classes. You're totally right. I know there are one or two renderers that extends from the base one, but I think in this case that code should be copied to html5 codebase. There were many more in the past extending base ones, and I haven't checked that our recently. @Leo, thanks for your analysis. I will get rid of the dependency to myfaces-shared. Greetings, Ali On Mon, Mar 21, 2011 at 12:31 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi The latest code committed on shared branch indicates the objective is add a submodule of shared project, just like shared-tomahawk and shared-orchestra. http://svn.apache.org/repos/asf/myfaces/shared/trunk/shared-html5/ From a theorical point of view, html5 project should not use a shared submodule. The reason is there is not an strong reason why use it. Below there is the list of the projects using shared and the reasons why do that. - Tomahawk requires a shared module because it has components that extends from the base components and it extends the base renderers. - Portlet-brigde requires reuse some classes related with view handling. - Orchestra really does not requires shared, because currently it only uses some utility code that deals with classes and a base class for tag classes. In the future, orchestra will use myfaces-commons-utils instead shared. - The code available on html5 project uses some utility methods for rendering code. Myfaces commons utils is a project on myfaces with the intention of provide a common place where utility methods used in JSF related libraries. In few words, it is a long term replacement of shared. The idea is move with care the utility methods used on shared and build a stable API. Later, projects like myfaces orchestra, myfaces html5 and others could take advantage and use that code, just adding it as a compile dependency. The current javadoc of myfaces-commons-utils is here: http://myfaces.apache.org/commons20/myfaces-commons-utils20/apidocs/index.html From this point of view, instead create a shared html5 module, we should check which code is used by its renderers and create the files necessary on myfaces-commons-utils that provides those utility methods. Note it is not a copy of shared, some methods could have changes in its signature or could be located in other classes. I know there are one or two renderers that extends from the base one, but I think in this case that code should be copied to html5 codebase. I would like to do this before any release of html5, but note this is not a blocker issue. In one way or another, you'll need to do two release procedures (shared and html5 or commons for jsf 2.0 and html5). regards, Leonardo Uribe 2011/3/20 Scott O'Bryan darkar...@gmail.com: AFAIK, tomahawk is the only project that does it that way. I suppose my question is this. Is html5 going to use every release of shared or will it only uptake a release when it needs to? If the later, then all it really does is take up extra space in svn. On Mar 20, 2011, at 7:09 AM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi scott, ali. As ali mentioned, it was my idea to put the shared html5 module into the shared project. And this is the way it should be IMO. Look at shared_impl and shared_tomahawk for example. Also: there is no need to split up the shared and the html5 release. They can be done together. For reference: look how Leonardo did the last MyFaces core releases in the wiki. If you want, Ali, I can help you with the release next week! Regards, Jakob Am Sonntag, 20. März 2011 schrieb Scott O'Bryan darkar...@gmail.com: I'll see if I can't cough up an example later tonight. On Mar 19, 2011, at 7:09 PM, Scott O'Bryan darkar...@gmail.com wrote: No, your not getting me. MyFaces-shared-orchestra does not exist in MyFaces shared, it exists in Orchestra.. That's where I got the process I used in early releases of the 3.0 bridge and Matthias used in Trinidad. The difference is that for these other modules, he shared is build during PROJECT building/release whereas with tomahawk, it is done during the shared release. (ie. You will never see a shared-bridge in the shared package. It exists only
Re: Html5 Component Library - Alpha Release
Hi, From this point of view, instead create a shared html5 module, we should check which code is used by its renderers and create the files necessary on myfaces-commons-utils that provides those utility methods. Note it is not a copy of shared, some methods could have changes in its signature or could be located in other classes. You're totally right. I know there are one or two renderers that extends from the base one, but I think in this case that code should be copied to html5 codebase. There were many more in the past extending base ones, and I haven't checked that our recently. @Leo, thanks for your analysis. I will get rid of the dependency to myfaces-shared. Greetings, Ali On Mon, Mar 21, 2011 at 12:31 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi The latest code committed on shared branch indicates the objective is add a submodule of shared project, just like shared-tomahawk and shared-orchestra. http://svn.apache.org/repos/asf/myfaces/shared/trunk/shared-html5/ From a theorical point of view, html5 project should not use a shared submodule. The reason is there is not an strong reason why use it. Below there is the list of the projects using shared and the reasons why do that. - Tomahawk requires a shared module because it has components that extends from the base components and it extends the base renderers. - Portlet-brigde requires reuse some classes related with view handling. - Orchestra really does not requires shared, because currently it only uses some utility code that deals with classes and a base class for tag classes. In the future, orchestra will use myfaces-commons-utils instead shared. - The code available on html5 project uses some utility methods for rendering code. Myfaces commons utils is a project on myfaces with the intention of provide a common place where utility methods used in JSF related libraries. In few words, it is a long term replacement of shared. The idea is move with care the utility methods used on shared and build a stable API. Later, projects like myfaces orchestra, myfaces html5 and others could take advantage and use that code, just adding it as a compile dependency. The current javadoc of myfaces-commons-utils is here: http://myfaces.apache.org/commons20/myfaces-commons-utils20/apidocs/index.html From this point of view, instead create a shared html5 module, we should check which code is used by its renderers and create the files necessary on myfaces-commons-utils that provides those utility methods. Note it is not a copy of shared, some methods could have changes in its signature or could be located in other classes. I know there are one or two renderers that extends from the base one, but I think in this case that code should be copied to html5 codebase. I would like to do this before any release of html5, but note this is not a blocker issue. In one way or another, you'll need to do two release procedures (shared and html5 or commons for jsf 2.0 and html5). regards, Leonardo Uribe 2011/3/20 Scott O'Bryan darkar...@gmail.com: AFAIK, tomahawk is the only project that does it that way. I suppose my question is this. Is html5 going to use every release of shared or will it only uptake a release when it needs to? If the later, then all it really does is take up extra space in svn. On Mar 20, 2011, at 7:09 AM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi scott, ali. As ali mentioned, it was my idea to put the shared html5 module into the shared project. And this is the way it should be IMO. Look at shared_impl and shared_tomahawk for example. Also: there is no need to split up the shared and the html5 release. They can be done together. For reference: look how Leonardo did the last MyFaces core releases in the wiki. If you want, Ali, I can help you with the release next week! Regards, Jakob Am Sonntag, 20. März 2011 schrieb Scott O'Bryan darkar...@gmail.com: I'll see if I can't cough up an example later tonight. On Mar 19, 2011, at 7:09 PM, Scott O'Bryan darkar...@gmail.com wrote: No, your not getting me. MyFaces-shared-orchestra does not exist in MyFaces shared, it exists in Orchestra.. That's where I got the process I used in early releases of the 3.0 bridge and Matthias used in Trinidad. The difference is that for these other modules, he shared is build during PROJECT building/release whereas with tomahawk, it is done during the shared release. (ie. You will never see a shared-bridge in the shared package. It exists only in the portlet Bridge's impl package.) On Mar 19, 2011, at 6:59 PM, Ali Ok al...@aliok.com.tr wrote: Hi, Ali, I think I'd suggest actually doing this like Trinidad, Orchestra, and the Portlet Bridge do this in that they actually download the main shared and instrument to code when THIER impl builds. Yep, that is what myfaces-shared-html5 build is doing, just like
[jira] [Created] (MFHTML5-1) Get rid of myfaces-shared-html5 dependency
Get rid of myfaces-shared-html5 dependency -- Key: MFHTML5-1 URL: https://issues.apache.org/jira/browse/MFHTML5-1 Project: MyFaces HTML5 Component Library Issue Type: Improvement Components: Component Library Affects Versions: 1.0.0-alpha-SNAPSHOT Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MFHTML5-2) Delete myfaces-shared-html5 project
Delete myfaces-shared-html5 project --- Key: MFHTML5-2 URL: https://issues.apache.org/jira/browse/MFHTML5-2 Project: MyFaces HTML5 Component Library Issue Type: Task Components: Component Library Affects Versions: 1.0.0-alpha-SNAPSHOT Reporter: Ali Ok Assignee: Ali Ok -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Html5 Component Library - Alpha Release
Hi all, Can someone experienced help me with releasing the first alpha of the project? Code is at http://svn.apache.org/repos/asf/myfaces/html5/ Project uses a new myfaces-shared project : myfaces-shared-html5[0]. Since myfaces-shared version which I moved myfaces-shared-html5 (4.0.6) is not released, first it needs to be released. Thus, for building the project, I needed to install myfaces-shared-html5 on my local repository. May be we should discuss the further process of the release of Html5 project, after discussing/doing the new release of myfaces-shared-* . [0] http://svn.apache.org/repos/asf/myfaces/shared/trunk/shared-html5/ http://svn.apache.org/repos/asf/myfaces/html5/Thanks, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Html5 Component Library - Alpha Release
Hi, Ali, I think I'd suggest actually doing this like Trinidad, Orchestra, and the Portlet Bridge do this in that they actually download the main shared and instrument to code when THIER impl builds. Yep, that is what myfaces-shared-html5 build is doing, just like myfaces-shared-impl, myfaces-shared-tomahawk and myfaces-shared-orchestra (of branch 2.0.x). They are also submodules of myfaces-shared, and they are released with it. If that's not acceptable, you can simply install your new shared project under trunk and use that. First, it was like that: the myfaces-shared-html5 was a submodule of Html5 project. However, as Jakob suggested in another thread, that project is better to be a submodule of myfaces-shared, just like others. I think myfaces-shared (in fact, in this case only the submodule myfaces-shared-html5) release is necessary, since the submodule myfaces-shared-html5 is a dependency of Html5 project and it is not released yet. Thanks, Ali On Sun, Mar 20, 2011 at 2:21 AM, Scott O'Bryan darkar...@gmail.com wrote: Ali, I think I'd suggest actually doing this like Trinidad, Orchestra, and the Portlet Bridge do this in that they actually download the main shared and instrument to code when THIER impl builds. That way you don't have to release shared. If that's not acceptable, you can simply install your new shared project under trunk and use that. I would wait until HTML5 is ready for a release before releasing the shared project. Scott On Mar 19, 2011, at 6:12 PM, Ali Ok al...@aliok.com.tr wrote: Hi all, Can someone experienced help me with releasing the first alpha of the project? Code is at http://svn.apache.org/repos/asf/myfaces/html5/ http://svn.apache.org/repos/asf/myfaces/html5/ Project uses a new myfaces-shared project : myfaces-shared-html5[0]. Since myfaces-shared version which I moved myfaces-shared-html5 (4.0.6) is not released, first it needs to be released. Thus, for building the project, I needed to install myfaces-shared-html5 on my local repository. May be we should discuss the further process of the release of Html5 project, after discussing/doing the new release of myfaces-shared-* . [0] http://svn.apache.org/repos/asf/myfaces/shared/trunk/shared-html5/ http://svn.apache.org/repos/asf/myfaces/shared/trunk/shared-html5/ http://svn.apache.org/repos/asf/myfaces/html5/Thanks, Ali -- My Blog: http://blog.aliok.com.trhttp://blog.aliok.com.tr Twitter: http://twitter.com/aliok_trhttp://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: PMC chair of Apache MyFaces changed
Congrats Gerard. I hope we'll see you around Matthias. Greetings, Ali On Thu, Mar 17, 2011 at 7:43 PM, Blake Sullivan blake.sulli...@oracle.comwrote: Matthias, Thanks for all of your hard work. Gerhard, congratulations and I look forward to working with you. -- Blake On 3/17/11 12:20 AM, Matthias Wessendorf wrote: Hi, I am stepping back from being the Apache MyFaces PMC chair. The MyFaces PMC did vote (internally) that Gerhard Petracek would be a very good PMC chair. Yesterday, during the board meeting, this has been made official. Please join me in welcoming Gerhard as being the new PMC chair of Apache MyFaces! Congrats, Gerhard! -Matthias -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Html5 Component Library - Status and Demo
Hi, Can you also give me the rights for administrating the MFHTML5? I will add versions/components/releases etc. Thanks. On Tue, Mar 8, 2011 at 5:01 PM, Ali Ok al...@aliok.com.tr wrote: Thanks Matthias. Greetings, Ali On Tue, Mar 8, 2011 at 4:47 PM, Matthias Wessendorf mat...@apache.orgwrote: Done. https://issues.apache.org/jira/browse/MFHTML5 On Tue, Mar 8, 2011 at 2:41 PM, Ali Ok al...@aliok.com.tr wrote: Hello Manfred, Could you create the subproject of Myfaces with key MFHTML5 please? Thanks, Ali On Mon, Mar 7, 2011 at 3:38 PM, Gerhard gerhard.petra...@gmail.com wrote: hi ali, manfred is able to create it. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/3/7 Ali Ok al...@aliok.com.tr Hi all, Can someone with the administration right create the new project in JIRA? I want to go on with the further process after that (preparing an alpha release). Thanks, Ali On Mon, Jan 31, 2011 at 7:31 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Ali, Great to hear! I think we should create the project in the JIRA (e.g. MFHTML5, as discussed), move it into myfaces/html5 and do a first alpha release. WDYT guys? Regards, Jakob 2011/1/31 Ali Ok al...@aliok.com.tr: Hi all, I've deployed a new version of my webapp which demonstrates Html5 component library at http://bit.ly/myfaces-html5-demo This demo is based on the one presented in JavaOne, but I've removed all third party Apache License incompatible code and resources. So, the demo will be a subproject of the component library. I've added several new components and features into the component lib and I think now it is a good time for an alpha release. Having a JIRA space would be a great first step. PS: Sorry about the low speed of the demo, it is deployed on Google App Engine. The source code is here Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Html5 Component Library - Status and Demo
Hello Manfred, Could you create the subproject of Myfaces with key MFHTML5 please? Thanks, Ali On Mon, Mar 7, 2011 at 3:38 PM, Gerhard gerhard.petra...@gmail.com wrote: hi ali, manfred is able to create it. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/3/7 Ali Ok al...@aliok.com.tr Hi all, Can someone with the administration right create the new project in JIRA? I want to go on with the further process after that (preparing an alpha release). Thanks, Ali On Mon, Jan 31, 2011 at 7:31 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Ali, Great to hear! I think we should create the project in the JIRA (e.g. MFHTML5, as discussed), move it into myfaces/html5 and do a first alpha release. WDYT guys? Regards, Jakob 2011/1/31 Ali Ok al...@aliok.com.tr: Hi all, I've deployed a new version of my webapp which demonstrates Html5 component library at http://bit.ly/myfaces-html5-demo This demo is based on the one presented in JavaOne, but I've removed all third party Apache License incompatible code and resources. So, the demo will be a subproject of the component library. I've added several new components and features into the component lib and I think now it is a good time for an alpha release. Having a JIRA space would be a great first step. PS: Sorry about the low speed of the demo, it is deployed on Google App Engine. The source code is here Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Html5 Component Library - Status and Demo
Thanks Matthias. Greetings, Ali On Tue, Mar 8, 2011 at 4:47 PM, Matthias Wessendorf mat...@apache.orgwrote: Done. https://issues.apache.org/jira/browse/MFHTML5 On Tue, Mar 8, 2011 at 2:41 PM, Ali Ok al...@aliok.com.tr wrote: Hello Manfred, Could you create the subproject of Myfaces with key MFHTML5 please? Thanks, Ali On Mon, Mar 7, 2011 at 3:38 PM, Gerhard gerhard.petra...@gmail.com wrote: hi ali, manfred is able to create it. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/3/7 Ali Ok al...@aliok.com.tr Hi all, Can someone with the administration right create the new project in JIRA? I want to go on with the further process after that (preparing an alpha release). Thanks, Ali On Mon, Jan 31, 2011 at 7:31 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Ali, Great to hear! I think we should create the project in the JIRA (e.g. MFHTML5, as discussed), move it into myfaces/html5 and do a first alpha release. WDYT guys? Regards, Jakob 2011/1/31 Ali Ok al...@aliok.com.tr: Hi all, I've deployed a new version of my webapp which demonstrates Html5 component library at http://bit.ly/myfaces-html5-demo This demo is based on the one presented in JavaOne, but I've removed all third party Apache License incompatible code and resources. So, the demo will be a subproject of the component library. I've added several new components and features into the component lib and I think now it is a good time for an alpha release. Having a JIRA space would be a great first step. PS: Sorry about the low speed of the demo, it is deployed on Google App Engine. The source code is here Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: html5 lib
Hi, Current location of the code is : http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/ and subprojects: * http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/trunk/html5-comp-lib-core/ * http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/trunk/html5-comp-lib-examples/ * http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/trunk/myfaces-shared-html5/ What about http://svn.apache.org/repos/asf/myfaces/html5/ ? * http://svn.apache.org/repos/asf/myfaces/html5/trunk/html5-comp-lib-core/ * http://svn.apache.org/repos/asf/myfaces/html5/trunk/html5-comp-lib-examples/ * http://svn.apache.org/repos/asf/myfaces/html5/trunk/myfaces-shared-html5/ http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/I remember I've read about a decision not adding another top level folder (not 100% sure). Is that so? Cheers, Ali On Thu, Jan 20, 2011 at 1:23 PM, Matthias Wessendorf mat...@apache.orgwrote: +1 let me use that... On Thu, Jan 20, 2011 at 12:16 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Maybe MFHTML5 like we did in MyFaces commons (-- MFCOMMONS). Regards, Jakob Am Donnerstag, 20. Januar 2011 schrieb Matthias Wessendorf mat...@apache.org: the issue is, something like MYFACES-HTML5 does not work (because of -) :-) On Thu, Jan 20, 2011 at 8:18 AM, Gerhard gerhard.petra...@gmail.com wrote: +1 for a new jira project regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/1/20 Matthias Wessendorf mat...@apache.org Question: Should we add a new JIRA project (MYFACESHTML5) Or is it enough to have a HTML5 component ? I personally don't mind having a new project for it.. -M On Thu, Jan 20, 2011 at 6:06 AM, Matthias Wessendorf mat...@apache.org wrote: Nope On Wednesday, January 19, 2011, Ali Ok al...@aliok.com.tr wrote: Hi, totally - let's create a jira instance for myfaces-html5 ?Do we need voting for this? Cheers,Ali On Tue, Jan 18, 2011 at 3:50 PM, Ali Ok al...@aliok.com.tr wrote: Hi, For example, for the hx:video component there is a fallback facet. But I can't say we're able cope with this problem (yet). So far, I've experimented Html5, CSS and other Javascript APIs; created some components, behaviors and etc. Providing fallbacks automatically is not that easy and for some features, it is impossible. Of course, we would have allow users to plug in their fallbacks.That would be an important part of this project. How do others cope with this situation? Is there an established pattern for this case? If so, then we should add it to our WIKI.There is a Javascript library called Modernizr [1] which can detect the support for features. AFAIK, people use that to use Html5 features or fallback to old stuff. Furthermore, Html side of the Html5 (Html + JS APIs + CSS3) mostly designed in a way that old browsers will just ignore the component, but not it's children elements. So, that is another way of providing fallbacks, as nested elements, since new browsers will consider the Html5 elements, but ignore it's non-applicable children. [1] https://github.com/Modernizr/Modernizr Greetings,Ali On Tue, Jan 18, 2011 at 3:31 PM, Mark Struberg strub...@yahoo.de wrote: Please allow me a question (I'm a complete noob on this topic), just for getting the 'big picture': The html5 components are obviously only for html-5 compatible browsers. Is there a strategy to also serve older (xhtml-4 only) browsers? Or do we just show them a 'not available for your old browser' page in this case? How do others cope with this situation? Is there an established pattern for this case? If so, then we should add it to our WIKI. LieGrue, strub --- On Tue, 1/18/11, Matthias Wessendorf mat...@apache.org wrote: From: Matthias Wessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[jira] Resolved: (MYFACES-2632) HTML 5 renderkit for MyFaces
[ https://issues.apache.org/jira/browse/MYFACES-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali Ok resolved MYFACES-2632. - Resolution: Fixed I think we can resolve and close this issue. HTML 5 renderkit for MyFaces Key: MYFACES-2632 URL: https://issues.apache.org/jira/browse/MYFACES-2632 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Labels: gsoc, mentor running into this document: http://diveintohtml5.org/forms.html I started playing with some of the new widgets in my Chromium browser (I wasn't aware that spinbox/sliders are part of HTML5). What about trying to find someone for a GSoC project, to add a (raw) HTML 5 renderkit? Bernd and I talked about a potential renderkit last time we saw each other, but now there is actually some (raw) support on it inside of some browsers... Why not introducing an hx:*** namespace that could contain stuff as the following: -hx:inputRangeSlider -hx:inputColor -hx:whatEverNewWidgetIsPartOfHTML5 / And/or some more functional stuff, like drag-and-drop: -fx:dragAndDrop... (could be done as a behavior) etc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Html5 Component Library - Status and Demo
Hi all, Can someone with the administration right create the new project in JIRA? I want to go on with the further process after that (preparing an alpha release). Thanks, Ali On Mon, Jan 31, 2011 at 7:31 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Ali, Great to hear! I think we should create the project in the JIRA (e.g. MFHTML5, as discussed), move it into myfaces/html5 and do a first alpha release. WDYT guys? Regards, Jakob 2011/1/31 Ali Ok al...@aliok.com.tr: Hi all, I've deployed a new version of my webapp which demonstrates Html5 component library at http://bit.ly/myfaces-html5-demo This demo is based on the one presented in JavaOne, but I've removed all third party Apache License incompatible code and resources. So, the demo will be a subproject of the component library. I've added several new components and features into the component lib and I think now it is a good time for an alpha release. Having a JIRA space would be a great first step. PS: Sorry about the low speed of the demo, it is deployed on Google App Engine. The source code is here Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[jira] Commented: (EXTVAL-126) Implement the DateIsType.beforeOrSame and DateIsType.afterOrSame date comparisons
[
https://issues.apache.org/jira/browse/EXTVAL-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12990482#comment-12990482
]
Ali Ok commented on EXTVAL-126:
---
Turkish:
wrong_date_not_before_or_same=Tarih, {0} tarihine eşit veya ondan daha sonra
olmalıdır.
wrong_date_not_after_or_same=Tarih, {0} tarihine eşit veya ondan daha önce
olmalıdır.
Implement the DateIsType.beforeOrSame and DateIsType.afterOrSame date
comparisons
-
Key: EXTVAL-126
URL: https://issues.apache.org/jira/browse/EXTVAL-126
Project: MyFaces Extensions Validator
Issue Type: Improvement
Components: Property Validation
Affects Versions: 1.2.4, 2.0.4
Reporter: Rudy De Busscher
Priority: Minor
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Html5 Component Library - Status and Demo
Hi all, I've deployed a new version of my webapp which demonstrates Html5 component library at http://bit.ly/myfaces-html5-demo This demo is based on the one presented in JavaOne, but I've removed all third party Apache License incompatible code and resources. So, the demo will be a subproject of the component library. http://bit.ly/myfaces-html5-demoI've added several new components and features into the component lib and I think now it is a good time for an alpha release. Having a JIRA space would be a great first step. PS: Sorry about the low speed of the demo, it is deployed on Google App Engine. The source code is herehttps://github.com/aliok/javaone-myfaces-html5-demo/ Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: html5 lib
Hi, I don't have any suggestions about the location, but I have a request related to this context. To ease the contribution and use of other people, I think a Hudson build and JIRA space would be useful. What do you think about that? Greetings, Ali On Tue, Jan 18, 2011 at 2:15 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi, IMO we should add it as a new MyFaces component lib (of course, only after a successful vote). Regards, Jakob 2011/1/18 Matthias Wessendorf mat...@apache.org: hi, where should we place the html5 stuff, that Ali did during summer of code? Like what folder etc ? It's time to get a first alpha out.. and the location should be a stopper (release often - release early) -M -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: HTML 5 Module: aplha 1 ?
Hi all, That would be great. Sent from Android On 17 Nov 2010 18:45, Gerhard gerhard.petra...@gmail.com wrote: i agree with jakob regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/11/17 Jakob Korherr jakob.korh...@gmail.com Hi, IMO we should discuss where to put the GSoC projects and thus how they should be packaged first (especially HTML5 and webapptest). Currently they're still in the gsoc folder. Regards, Jakob 2010/11/17 Matthias Wessendorf mat...@apache.org: Hi Should we release a first alpha? sent from my Android phone -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Created: (MYFACES-2962) Descriptions of components, attributes, etc. are missing in taglib.xml files generated by MyFaces Builder Plugin
Descriptions of components, attributes, etc. are missing in taglib.xml files generated by MyFaces Builder Plugin Key: MYFACES-2962 URL: https://issues.apache.org/jira/browse/MYFACES-2962 Project: MyFaces Core Issue Type: Improvement Components: build process Affects Versions: 2.0.2 Reporter: Ali Ok Assignee: Ali Ok Descriptions of components, attributes, etc. are missing in taglib.xml files generated by MyFaces Builder Plugin. Those documentations are used in most IDES (AFAIK Eclipse and Intellij). Of course most IDEs cache the documentation for standard Html libraries, but they read the documentation from taglib.xml file for the other libraries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2606) javax.crypto.BadPaddingException on Google App Engine
[ https://issues.apache.org/jira/browse/MYFACES-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali Ok resolved MYFACES-2606. - Resolution: Invalid Fix Version/s: 2.0.3-SNAPSHOT javax.crypto.BadPaddingException on Google App Engine - Key: MYFACES-2606 URL: https://issues.apache.org/jira/browse/MYFACES-2606 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Environment: Google App Engine Reporter: Ali Ok Assignee: Ali Ok Fix For: 2.0.3-SNAPSHOT javax.crypto.BadPaddingException is thrown after some time (a few minutes) while restoring the state on Google App Engine. Some discussion on https://issues.apache.org/jira/browse/MYFACES-2559. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2606) javax.crypto.BadPaddingException on Google App Engine
[ https://issues.apache.org/jira/browse/MYFACES-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921769#action_12921769 ] Ali Ok commented on MYFACES-2606: - This is the expected behavior on Google App Engine. Users need to define the org.apache.myfaces.SECRET context param to prevent this error. This is also mentioned in MyFaces App Engine support documentation. Marking as invalid. javax.crypto.BadPaddingException on Google App Engine - Key: MYFACES-2606 URL: https://issues.apache.org/jira/browse/MYFACES-2606 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Environment: Google App Engine Reporter: Ali Ok Assignee: Ali Ok Fix For: 2.0.3-SNAPSHOT javax.crypto.BadPaddingException is thrown after some time (a few minutes) while restoring the state on Google App Engine. Some discussion on https://issues.apache.org/jira/browse/MYFACES-2559. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2939) f:event type=postValidate does not work
[
https://issues.apache.org/jira/browse/MYFACES-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12918686#action_12918686
]
Ali Ok commented on MYFACES-2939:
-
I tested this on Tomcat and Jetty, not working on them as well (aside from GAE).
Not checked the spec whether something wrong about the coding here, but since
it works in Mojarra, this seems like a bug.
f:event type=postValidate does not work
---
Key: MYFACES-2939
URL: https://issues.apache.org/jira/browse/MYFACES-2939
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.2
Environment: All
Reporter: Werner Punz
From the mailinglist following bug was reported by Nikolai Rychkov
(I have to add I could reproduce the bug here on my machine as well, even
with a field being set to required so that validation definitely is called)
Original Message:
I try this simple example. But event doesn't be invoked. It looks like
f:event type=postValidate doesn't work
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:head
meta http-equiv=Content-Type content=text/html; charset=UTF-8/
title/title
/h:head
h:body
h:form id=form
f:event type=postValidate listener=#{user.validate}/
h3Please enter your name and password./h3
table
tr
tdName:/td
tdh:inputText id=name value=#{user.name}//td
/tr
tr
tdPassword:/td
tdh:inputSecret id=password
value=#{user.password}//td
/tr
/table
ph:commandButton id=button value=Login action=welcome//p
/h:form
/h:body
/html
@ManagedBean(name = user)
@SessionScoped
public class UserBean implements Serializable {
private Logger log = LoggerFactory.getLogger(UserBean.class);
private String name;
private String password;
private static final long serialVersionUID = -7858335225156624734L;
public String getName() {return name;}
public void setName(String newValue) {name = newValue;}
public String getPassword() {return password;}
public void setPassword(String newValue) {password = newValue;
}
public void validate(ComponentSystemEvent e) {
log.info();
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: GSoC Final
Hi, I highly recommend that you work out showing the examples in the demo, though :-). Yeah, you're right :) Here is the J1 Demo : The demo is deployed on Google App Engine : http://bit.ly/myfaces-html5-j1-demo http://bit.ly/myfaces-html5-j1-demoMost pages work in Chrome, but some of them work in Firefox and Opera. You can find the notes about browsers at right-bottom of each slide. Best, Ali On Wed, Aug 18, 2010 at 5:13 PM, Kito Mann kito.m...@virtua.com wrote: Good work, Ali! I highly recommend that you work out showing the examples in the demo, though :-). --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Sat, Aug 14, 2010 at 7:32 PM, Ali Ok al...@aliok.com.tr wrote: Hi, GSoC final is tomorrow. So here is my final work (I mean during the GSoC period): SVN folder (tagged for GSoC final) : http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/tags/gsoc_final/ Project website : http://people.apache.org/~aliok/GSoC/tagged/html5-comp-lib-project/target/site/index.html Slides : http://people.apache.org/~aliok/GSoC/tagged/slide/MyFaces2-Html5-Comp-Lib-Tagged.ppt Online showcase : http://html5-comp-lib-showcase-snapshot.latest.aliok-com-tr-test.appspot.com/index.jsf I'll be around and participate in the development of MyFaces. I'll continue to work on Html5 support too. There are great stuff I cannot find time to work on during 3 month GSoC period. I want to thank all of you for your help and feedback during GSoC. Special thanks to my mentor, Matthias, for his guidance and help. Best wishes, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [jsr-314-open] JSF gathering @ JavaOne (was Re: MyFaces @JavaOne?)
+1 on Thursday. On Tue, Sep 21, 2010 at 12:58 AM, Hazem Saleh haz...@apache.org wrote: Iam OK to meet on Thursday anytime. On Mon, Sep 20, 2010 at 11:13 PM, Kito Mann kito.m...@virtua.com wrote: We're thinking Thursday might be good for some drinks, if anyone is still around. Sent from my iPhone http://www.jsfcentral.com http://www.Virtua.com On Sep 20, 2010, at 8:31 PM, Matthias Wessendorf mat...@apache.org wrote: +1 on JCP event sent from my Android phone On Sep 20, 2010 5:55 PM, Edward Burns edward.bu...@oracle.com edward.bu...@oracle.com wrote: On 9/20/10 13:19 , Edward Burns wrote: On 9/19/10 20:34 , Kito Mann wrote: Sorry; highjacked the thread. I was talking about going out for drinks on Wed. I 100% want to be in on this. Kito, if I'm not there, can you please sms me the details? I suggest Wednesday before we all take the bus over to see Fergie [1]. Perhaps we meet near one of the conference bus stops? Ed [1] http://www.virginmedia.com/images/fergie-gal-forbes.jpg http://www.virginmedia.com/images/fergie-gal-forbes.jpg Also, I think we should just meet at the JCP reception. There might be free food and drink. http://jcp.orgjcp.org: Stop by the Pacific Terrace of the Intercontinental Hotel - (Map and Directions) Wednesday September 22 between 6PM and 8PM on your way to the Oracle Appreciation Event. Shuttle buses to Treasure Island will be available less than a block away. -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Web blog: http://www.jroller.com/HazemBlog [Web 2.0] Mashups Integration with JSF: http://code.google.com/p/mashups4jsf/ -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: GSoC Final
Hi, Are you supposed to give a live presentation on your project? I will do it but not with those slides :) This week I'm gonna try to integrate it in my side project Cool! Can I see the current Html5 client live? I've already added your session to my schedule. See you at J1 :) Cheers, On Mon, Aug 16, 2010 at 9:10 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Hi Ali, Nice work dude! Are you supposed to give a live presentation on your project? In that case, the code snippets and images are really tiny and probably not very good readable. You might want to make those a bit bigger. Oh and BTW, slide 14 is good (favorite team: NL). This week I'm gonna try to integrate it in my side project ( http://code.google.com/p/parleys-html5/). I'm doing a talk about this project at JavaOne. I'll mention your work there. Regards, Jan-Kees 2010/8/16 Bruno Aranda brunoara...@gmail.com Good job Ali and congrats! I have some troubles when clicking on the View sources links in the examples. Other than that is great! Cheers, Bruno On 16 August 2010 00:19, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Ali, You really did a great job for your GSoC project. Thanks for all your work! I'll be around and participate in the development of MyFaces. I'll continue to work on Html5 support too. There are great stuff I cannot find time to work on during 3 month GSoC period. That's just great - I am looking forward to it! Regards, Jakob 2010/8/15 Ali Ok al...@aliok.com.tr Hi, GSoC final is tomorrow. So here is my final work (I mean during the GSoC period): SVN folder (tagged for GSoC final) : http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/tags/gsoc_final/ Project website : http://people.apache.org/~aliok/GSoC/tagged/html5-comp-lib-project/target/site/index.html Slides : http://people.apache.org/~aliok/GSoC/tagged/slide/MyFaces2-Html5-Comp-Lib-Tagged.ppt Online showcase : http://html5-comp-lib-showcase-snapshot.latest.aliok-com-tr-test.appspot.com/index.jsf I'll be around and participate in the development of MyFaces. I'll continue to work on Html5 support too. There are great stuff I cannot find time to work on during 3 month GSoC period. I want to thank all of you for your help and feedback during GSoC. Special thanks to my mentor, Matthias, for his guidance and help. Best wishes, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: GSoC Final
Thanks Jakob and Bruno, The view sources links don't work on Google App Engine since the servlet tries to read from the file system. I might fix it later. Thanks for the heads-up. Cheers, On Mon, Aug 16, 2010 at 3:29 AM, Bruno Aranda brunoara...@gmail.com wrote: Good job Ali and congrats! I have some troubles when clicking on the View sources links in the examples. Other than that is great! Cheers, Bruno On 16 August 2010 00:19, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Ali, You really did a great job for your GSoC project. Thanks for all your work! I'll be around and participate in the development of MyFaces. I'll continue to work on Html5 support too. There are great stuff I cannot find time to work on during 3 month GSoC period. That's just great - I am looking forward to it! Regards, Jakob 2010/8/15 Ali Ok al...@aliok.com.tr Hi, GSoC final is tomorrow. So here is my final work (I mean during the GSoC period): SVN folder (tagged for GSoC final) : http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/tags/gsoc_final/ Project website : http://people.apache.org/~aliok/GSoC/tagged/html5-comp-lib-project/target/site/index.html Slides : http://people.apache.org/~aliok/GSoC/tagged/slide/MyFaces2-Html5-Comp-Lib-Tagged.ppt Online showcase : http://html5-comp-lib-showcase-snapshot.latest.aliok-com-tr-test.appspot.com/index.jsf I'll be around and participate in the development of MyFaces. I'll continue to work on Html5 support too. There are great stuff I cannot find time to work on during 3 month GSoC period. I want to thank all of you for your help and feedback during GSoC. Special thanks to my mentor, Matthias, for his guidance and help. Best wishes, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: MyFaces @JavaOne?
- *Dan Allen* - *Ed Burns* - Hazem - *David Geary* - *Alexander Smirnov,* - *Roger Kitain* are other JSF folks I know, apart from mentioned people before. Cheers, On Mon, Aug 16, 2010 at 4:17 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Ah nice, see you there! Other JSF folks going as well? /JK 2010/8/16 Matthias Wessendorf mat...@apache.org Howdy, Ali and I are speaking on Thursday, What's cool in Apache MyFaces (containing CODI, Trinidad mobile, HTML5...) -Matthias On Mon, Aug 16, 2010 at 10:05 AM, Jakob Korherr jakob.korh...@gmail.com wrote: As far as I know, Matthias and Ali will also be there! 2010/8/16 Werner Punz werner.p...@gmail.com Am 16.08.10 09:31, schrieb Jan-Kees van Andel: Hi, Just wondering, are any of you guys heading to JavaOne this year? It's not as big as last years, but still a very cool conference I think. Anyway, I'm going and I'm doing a talk with Stephan Janssen about our project on Thursday: The JavaServer Faces (JSF) 2.0 and HTML5 Version of Parleys.com Other MyFaces (or regular JSF) folks attending/speaking at J1? Regards, Jan-Kees I think Matthias is there, isn´t he, I am not sure if somone from Irian is there as well. -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
GSoC Final
Hi, GSoC final is tomorrow. So here is my final work (I mean during the GSoC period): SVN folder (tagged for GSoC final) : http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/tags/gsoc_final/ Project website : http://people.apache.org/~aliok/GSoC/tagged/html5-comp-lib-project/target/site/index.html Slides : http://people.apache.org/~aliok/GSoC/tagged/slide/MyFaces2-Html5-Comp-Lib-Tagged.ppt Online showcase : http://html5-comp-lib-showcase-snapshot.latest.aliok-com-tr-test.appspot.com/index.jsf I'll be around and participate in the development of MyFaces. I'll continue to work on Html5 support too. There are great stuff I cannot find time to work on during 3 month GSoC period. I want to thank all of you for your help and feedback during GSoC. Special thanks to my mentor, Matthias, for his guidance and help. Best wishes, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [BUILDTOOLS] Using Velocity Macros for generating source
On Tue, Aug 10, 2010 at 3:27 AM, Leonardo Uribe lu4...@gmail.com wrote: I remember some issues related to velocity and maven site plugin, so we need first to check if the change allows build myfaces core site (maven site plugin requires velocity 1.4, but myfaces builder plugin requires velocity 1.5). Yeah, I experienced those issues, but updates below fixed the problem: commons-lang 2.1 -- 2.4 doxia-site-renderer 1.0-alpha-7 -- 1.1.3 velocity 1.5 -- 1.6.4 and may be maven-dependency-plugin 2.0 -- 2.1 I'll create a diff for generated stuff of Myfaces core, comparing generated with current plugin and generated with updated one. Then we can discuss again. Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[BUILDTOOLS] Using Velocity Macros for generating source
Hi,
Currently, we don't use Velocity macros in the templates for generating
sources. At least we can use the macros defined in vm files, although there
is an option for writing Java code for macros (which is less preferred).
I've created https://issues.apache.org/jira/browse/MYFACES-2866 for this
issue.
So, for example, instead of
tag
..
#set ($propertyList = ${component.propertyList})
#foreach( $property in $propertyList )
#if (!$property.isTagExcluded())* attribute
#if ($property.longDescription)
description![CDATA[$property.longDescription]]/description
/attribute
#end*
#end
/tag
we could've used
tag
#set ($propertyList = ${component.propertyList})
#foreach( $property in $propertyList )
#if (!$property.isTagExcluded())
*#writeProperty($property)*
#end
/tag
where writeProperty macro can be defined in vm file, as explained in
http://velocity.apache.org/engine/devel/user-guide.html#Velocimacros
Furthermore, to reuse the macros in different vm files, there is parse [1]
directive. But myfaces-builder-plugin must migrate to Velocity 1.6 (see
https://issues.apache.org/jira/browse/MYFACES-2867) to parse the macros in
different vm files.
I checked out the myfaces-build-plugin, applied the mentioned changes
locally, used in generating sources of my GSoC project and worked
flawlessly (not committed yet).
Any concerns at first sight?
[1] http://velocity.apache.org/engine/devel/user-guide.html#Parse
http://velocity.apache.org/engine/devel/user-guide.html#ParseThanks,
Ali
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
[jira] Created: (MYFACES-2866) Use velocity macros in while generating resources and classes
Use velocity macros in while generating resources and classes - Key: MYFACES-2866 URL: https://issues.apache.org/jira/browse/MYFACES-2866 Project: MyFaces Core Issue Type: Improvement Components: build process Affects Versions: 2.0.1 Reporter: Ali Ok Instead of inline stuff, we should use Velocity macros. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2866) Use velocity macros in while generating resources and classes
[ https://issues.apache.org/jira/browse/MYFACES-2866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896299#action_12896299 ] Ali Ok commented on MYFACES-2866: - Also, to reuse the macros, we can use the #parse of Velocity 1.6. Or we will just copy-paste macros in each Velocity template. So I am creating a subtask for migrating to Velocity 1.6 Use velocity macros in while generating resources and classes - Key: MYFACES-2866 URL: https://issues.apache.org/jira/browse/MYFACES-2866 Project: MyFaces Core Issue Type: Improvement Components: build process Affects Versions: 2.0.1 Reporter: Ali Ok Instead of inline stuff, we should use Velocity macros. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2867) Migrate to Velocity 1.6
Migrate to Velocity 1.6 --- Key: MYFACES-2867 URL: https://issues.apache.org/jira/browse/MYFACES-2867 Project: MyFaces Core Issue Type: Sub-task Components: build process Affects Versions: 2.0.1 Reporter: Ali Ok To reuse the macros, we need to migrate to Velocity 1.6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2867) Migrate to Velocity 1.6
[ https://issues.apache.org/jira/browse/MYFACES-2867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896300#action_12896300 ] Ali Ok commented on MYFACES-2867: - To accomplish this, we need to migrate to commons-lang 2.1 -- 2.4 doxia-site-renderer 1.0-alpha-7 -- 1.1.3 velocity 1.5 -- 1.6.4 and may be maven-dependency-plugin 2.0 -- 2.1 I'll do this and share the results, but at first sight wdyt? Migrate to Velocity 1.6 --- Key: MYFACES-2867 URL: https://issues.apache.org/jira/browse/MYFACES-2867 Project: MyFaces Core Issue Type: Sub-task Components: build process Affects Versions: 2.0.1 Reporter: Ali Ok To reuse the macros, we need to migrate to Velocity 1.6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSoC] where to commit ?
Hi, I just created the folder http://svn.apache.org/repos/asf/myfaces/gsoc and put Html5 project into http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/trunk/ Greetings, Ali On Wed, Jul 28, 2010 at 3:54 PM, Matthias Wessendorf mat...@apache.orgwrote: Ok, Ali feel free to create the mentioned folder and your code to it! -Matthias On Mon, Jul 26, 2010 at 4:11 PM, Ali Ok al...@aliok.com.tr wrote: +1 On Mon, Jul 26, 2010 at 5:03 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/26 Matthias Wessendorf mat...@apache.org On Sat, Jul 24, 2010 at 3:49 PM, Mike Kienenberger mkien...@gmail.com wrote: I guess it depends on the goal. If the goal is to incorporate new code into MyFaces, then it is much easier to do it from the start as part of the on-going MyFaces project rather than as a code drop at the end. If the goal is to train the student up as an Apache committer, then it is much easier to do it when they are interacting with the code in our peer-reviewed environment. As we saw in the last vote thread, there's already a process in place to temporarily grant commit rights to GSoC students. To me, all the advantages are on the side of a GSoC folder here rather than a project located somewhere else. +1 On Sat, Jul 24, 2010 at 5:46 AM, Jakob Korherr jakob.korh...@gmail.com wrote: I don't know if this is really necessary. Most of our students already have google code projects and if we would create the GSoC folder, they all would need commit rights for it. Furthermore everyone can access those google-code-projects and we can discuss the proper location for each gsoc project after GSoC ends. Then the mentors (or mentees, if they have commit rights, like e.g. Ali) can migrate the code into our codebase to the proper location. Regards, Jakob 2010/7/23 Ali Ok al...@aliok.com.tr +1 from me too. /gsoc folder can also be used for next years. On Fri, Jul 23, 2010 at 9:44 PM, Matthias Wessendorf mat...@apache.org wrote: On Fri, Jul 23, 2010 at 8:22 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 for #1 (https://svn.apache.org/repos/asf/myfaces/gsoc/*) @relocation after gsoc finished: some time ago we decided that we won't add a lot of top-level modules. - imo we should decide about the final location of every gsoc-project later on. +1 that's totally my point. I don't care, right now, where they may end up ;-) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/23 Matthias Wessendorf mat...@apache.org Hey, I though about a proper location for the Google Summer of Code projects. What about this: https://svn.apache.org/repos/asf/myfaces/gsoc/projectXYZ/trunk/ Once the code is ready (stable) we can also relocate it, IMO. Like: https://svn.apache.org/repos/asf/myfaces/html5-lib/... https://svn.apache.org/repos/asf/myfaces/mab/... Any thoughts? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [GSoC] where to commit ?
+1 On Mon, Jul 26, 2010 at 5:03 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/26 Matthias Wessendorf mat...@apache.org On Sat, Jul 24, 2010 at 3:49 PM, Mike Kienenberger mkien...@gmail.com wrote: I guess it depends on the goal. If the goal is to incorporate new code into MyFaces, then it is much easier to do it from the start as part of the on-going MyFaces project rather than as a code drop at the end. If the goal is to train the student up as an Apache committer, then it is much easier to do it when they are interacting with the code in our peer-reviewed environment. As we saw in the last vote thread, there's already a process in place to temporarily grant commit rights to GSoC students. To me, all the advantages are on the side of a GSoC folder here rather than a project located somewhere else. +1 On Sat, Jul 24, 2010 at 5:46 AM, Jakob Korherr jakob.korh...@gmail.com wrote: I don't know if this is really necessary. Most of our students already have google code projects and if we would create the GSoC folder, they all would need commit rights for it. Furthermore everyone can access those google-code-projects and we can discuss the proper location for each gsoc project after GSoC ends. Then the mentors (or mentees, if they have commit rights, like e.g. Ali) can migrate the code into our codebase to the proper location. Regards, Jakob 2010/7/23 Ali Ok al...@aliok.com.tr +1 from me too. /gsoc folder can also be used for next years. On Fri, Jul 23, 2010 at 9:44 PM, Matthias Wessendorf mat...@apache.org wrote: On Fri, Jul 23, 2010 at 8:22 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 for #1 (https://svn.apache.org/repos/asf/myfaces/gsoc/*) @relocation after gsoc finished: some time ago we decided that we won't add a lot of top-level modules. - imo we should decide about the final location of every gsoc-project later on. +1 that's totally my point. I don't care, right now, where they may end up ;-) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/23 Matthias Wessendorf mat...@apache.org Hey, I though about a proper location for the Google Summer of Code projects. What about this: https://svn.apache.org/repos/asf/myfaces/gsoc/projectXYZ/trunk/ Once the code is ready (stable) we can also relocate it, IMO. Like: https://svn.apache.org/repos/asf/myfaces/html5-lib/... https://svn.apache.org/repos/asf/myfaces/mab/... Any thoughts? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [GSoC] where to commit ?
+1 from me too. /gsoc folder can also be used for next years. On Fri, Jul 23, 2010 at 9:44 PM, Matthias Wessendorf mat...@apache.orgwrote: On Fri, Jul 23, 2010 at 8:22 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 for #1 (https://svn.apache.org/repos/asf/myfaces/gsoc/*) @relocation after gsoc finished: some time ago we decided that we won't add a lot of top-level modules. - imo we should decide about the final location of every gsoc-project later on. +1 that's totally my point. I don't care, right now, where they may end up ;-) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/23 Matthias Wessendorf mat...@apache.org Hey, I though about a proper location for the Google Summer of Code projects. What about this: https://svn.apache.org/repos/asf/myfaces/gsoc/projectXYZ/trunk/ Once the code is ready (stable) we can also relocate it, IMO. Like: https://svn.apache.org/repos/asf/myfaces/html5-lib/... https://svn.apache.org/repos/asf/myfaces/mab/... Any thoughts? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [COMMUNITY] MyFaces += Ali Ok
I have to say I am very honored. Thanks again for inviting me. Let's have fun and develop great software :) Greetings, Ali On Thu, Jul 22, 2010 at 2:54 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Welcome, Ali :) Regards, Jakob 2010/7/22 Hazem Saleh haz...@apache.org Congratulations and welcome! On Thu, Jul 22, 2010 at 2:38 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: welcome! regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/22 Matthias Wessendorf mat...@apache.org The Myfaces PMC is proud to announce a new addition to our community. Please welcome Ali Ok as the newest MyFaces committer! Ali is an active member of the myfaces community, especially on MyFaces core and the HTML5 (gsoc) subproject. @Ali: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Web blog: http://hazems.blogetery.com/ [Web 2.0] Mashups Integration with JSF: http://code.google.com/p/mashups4jsf/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [GSOC] Html5 Support - Snapshot and Live Showcase
Hi all, I fixed some of the problems (like the NPE in DnD components) and updated dependencies to use latest MyFaces Core and subprojects. Here is the new snapshot : http://wiki.apache.org/myfaces/GSoC2010_HTML5?action=AttachFiledo=viewtarget=myfaces-html5-comp-lib-0.0.2-SNAPSHOT.zip Cheers, Ali On Thu, Jul 8, 2010 at 12:53 AM, Ali Ok al...@aliok.com.tr wrote: Hi, I've prepared some Html5 enabled components. Here is the source code of the component library project, and showcase project: http://wiki.apache.org/myfaces/GSoC2010_HTML5?action=AttachFiledo=viewtarget=myfaces-html5-comp-lib.zip http://wiki.apache.org/myfaces/GSoC2010_HTML5?action=AttachFiledo=viewtarget=myfaces-html5-comp-lib.zipI also deployed the showcase application on Google App Engine, but there are some problems(ie. the showcase servlet cannot display the page source) in the application running on it. Please just ignore them for now. http://html5-comp-lib-showcase-snapshot.latest.aliok-com-tr-test.appspot.com/index.jsf There should be no problem in building the mavenized source and doing a jetty:run on showcase application. Thanks in advance for your feedback. -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[GSOC] Html5 Support - Snapshot and Live Showcase
Hi, I've prepared some Html5 enabled components. Here is the source code of the component library project, and showcase project: http://wiki.apache.org/myfaces/GSoC2010_HTML5?action=AttachFiledo=viewtarget=myfaces-html5-comp-lib.zip http://wiki.apache.org/myfaces/GSoC2010_HTML5?action=AttachFiledo=viewtarget=myfaces-html5-comp-lib.zipI also deployed the showcase application on Google App Engine, but there are some problems(ie. the showcase servlet cannot display the page source) in the application running on it. Please just ignore them for now. http://html5-comp-lib-showcase-snapshot.latest.aliok-com-tr-test.appspot.com/index.jsf There should be no problem in building the mavenized source and doing a jetty:run on showcase application. Thanks in advance for your feedback. -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Trouble getting the value of a value expression in a datatable
Hi Leonardo,
Thanks for the explanation. I think I'll ignore this problem until the end
of the GSoC period, since it requires much time and may be its beyond me.
I'll request your help later.
Thanks,
Ali
On Mon, Jun 21, 2010 at 3:02 AM, Leonardo Uribe lu4...@gmail.com wrote:
Hi
That is because the fields that are saved per row (but not between request)
are the ones related to EditableValueHolder interface. Take a look at the
implementation of UIData. In this case value property goes per row but
param is shared by all rows.
This is a problem described on:
https://issues.apache.org/jira/browse/MYFACES-2616
Fix UIData state saving model (spec issue 153)
Really, there is not an easy solution for this issue. After thinking a lot
in this issue I think we can create a custom datatable component that has
this problem fixed, instead try to fix UIData implementation, because that
could cause compatibility problems (I'm not investigated too much that
suposition).
regards,
Leonardo Uribe
2010/6/20 Ali Ok al...@aliok.com.tr
Hi,
I am having problems with getting the value of an expression within a
datatable with my custom component.
Let me write the code:
h:dataTable value=#{dndBean.teams} var=team
h:column
hx:div
fx:dragSource action=move param=#{team.id} / !-- evaluates to
empty string --
h:outputText value=#{team.id} / !-- renders the correct id --
/hx:div
/h:column
/h:dataTable
dndBean: managed bean
dndBean.teams: ListSportsTeam, where SportsTeam has a public String
getId() method
team: var of datatable
I am getting a value of empty string for #{team.id} in the facelet
handler of fx:dragSource, if I put the fx:dragSource in a h:dataTable.
In the apply method of handler, I am trying to get the value as
_param.getValue(faceletContext) //use this method since deferredValueType
of _param is String
where _param is
@JSFFaceletAttribute(name = param, className =
javax.el.ValueExpression, deferredValueType = java.lang.String)
private final TagAttribute _param;
If I put the fx:dragSource somewhere else, I am getting the correct value
at the handler:
h:form
hx:div
fx:dragSource action=move param=#{lakers.id} /
/hx:div
/h:form
Why can this be happening?
One more hint, for the first case if I try to get the value at the
handler, I get empty string.
If I pass the value expression to behavior, and try to get the value at
renderer using the value expression, I am getting the correct value.
In theory, if the second case works, so does first one; right? Or am I
missing something?
Thanks,
Ali
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
Trouble getting the value of a value expression in a datatable
Hi,
I am having problems with getting the value of an expression within a
datatable with my custom component.
Let me write the code:
h:dataTable value=#{dndBean.teams} var=team
h:column
hx:div
fx:dragSource action=move param=#{team.id} / !-- evaluates to empty
string --
h:outputText value=#{team.id} / !-- renders the correct id --
/hx:div
/h:column
/h:dataTable
dndBean: managed bean
dndBean.teams: ListSportsTeam, where SportsTeam has a public String
getId() method
team: var of datatable
I am getting a value of empty string for #{team.id} in the facelet handler
of fx:dragSource, if I put the fx:dragSource in a h:dataTable.
In the apply method of handler, I am trying to get the value as
_param.getValue(faceletContext) //use this method since deferredValueType
of _param is String
where _param is
@JSFFaceletAttribute(name = param, className = javax.el.ValueExpression,
deferredValueType = java.lang.String)
private final TagAttribute _param;
If I put the fx:dragSource somewhere else, I am getting the correct value at
the handler:
h:form
hx:div
fx:dragSource action=move param=#{lakers.id} /
/hx:div
/h:form
Why can this be happening?
One more hint, for the first case if I try to get the value at the handler,
I get empty string.
If I pass the value expression to behavior, and try to get the value at
renderer using the value expression, I am getting the correct value.
In theory, if the second case works, so does first one; right? Or am I
missing something?
Thanks,
Ali
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
Re: [GSOC] myfaces-shared Modification
Thanks... On Mon, Jun 14, 2010 at 4:49 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Ali, I just committed your patch. Regards, Jakob 2010/6/8 Ali Ok al...@aliok.com.tr Here is the JIRA issue and the patch: https://issues.apache.org/jira/browse/MYFACES-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel Thanks, On Tue, Jun 8, 2010 at 12:24 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Ali, also +1 from me. The idea behind the XXXRendererBase classes on shared is that core and tomahawk use almost the same functionality here, tomahawk just adds one or more features to the existing behavior (like e.g. enabledOnUserRole). However you're right, it should be subdivided into better extendable parts rather than copied. Actually I am currently working on a little feature for Tomahawk 2.0 and I also was annoyed about this. So please create the JIRA issue and submit the patch. Maybe it will also help me with my work :) Regards, Jakob 2010/6/8 Matthias Wessendorf mat...@apache.org On Tue, Jun 8, 2010 at 9:17 AM, Ali Ok al...@aliok.com.tr wrote: Hi, myfaces-shared HtmlTextRendererBase : http://svn.apache.org/repos/asf/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTextRendererBase.java tomahawk HtmlTextRenderer : http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/core20/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlTextRenderer.java I saw these two long before, and decided to not to follow that approach. Files are almost identical, even if one extends another. As you see, shared HtmlTextRendererBase is not much extensible, ie. not fragmented into atomic parts or smthg. I want to use that base in my project too. So I made very simple modifications on that class: divided the long renderInput method into two protected methods without changing the behavior. Is it ok to do that? sure, big methods are always a pita. I will create a JIRA ticket and post the patch. +1 -M And I just wonder why authors kept that long method and copy-pasted it on Tomahawk? Is there something I'm not aware of? Regards, -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[jira] Created: (MYFACES-2746) Subdivide methods of HtmlTextRendererBase, HtmlTextareaRendererBase and HtmlSecretRendererBase into extendable parts
Subdivide methods of HtmlTextRendererBase, HtmlTextareaRendererBase and HtmlSecretRendererBase into extendable parts Key: MYFACES-2746 URL: https://issues.apache.org/jira/browse/MYFACES-2746 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0 Reporter: Ali Ok Subdivide the functionality in HtmlTextRendererBase, HtmlTextareaRendererBase and HtmlSecretRendererBase classes of myfaces-shared into better extendable parts. So, subclasses of these can extend these bases, rather than copying them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSOC] Implicit validation/conversion
Ok, got it. Thanks, On Tue, Jun 8, 2010 at 12:50 AM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Ali, Nope, it does it in the right phase and is used by UIComponent.getConvertedValue(). Regards, Jakob 2010/6/7 Ali Ok al...@aliok.com.tr Hi Leonardo, Shouldn't override Renderer.getConvertedValue(FacesContext, UIComponent, Object) work in this case? That approach makes the validation at the rendering phase, doesn't it? Is it OK to make such validation on that phase; after phases that do conversion, validation and model update? Thanks, Ali On Tue, Jun 8, 2010 at 12:36 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi Shouldn't override Renderer.getConvertedValue(FacesContext, UIComponent, Object) work in this case? regards, Leonardo Uribe 2010/6/7 Ali Ok al...@aliok.com.tr Hi, For hx:color component, I want to make sure sent value is a valid simple color[0]. e.g: #F0A1B2 This is a good use case for a converter, but necessity for automatic attaching makes things complicated. I tried the approaches below, all of them have some problems, and I don't want to follow them. * Overriding setValue(..) method in HtmlInputColor which is the component class :=) (breaks JSF lifecycle. Some manual validation is done, even though validator processing phase is over) * Attaching ColorValidator implements Validator at facelet handler * At facelet handler, attaching ColorConverter implements Converter which converts input to Color model pojo (a component can have one converter, so we should prevent other converters being attached, which is unacceptable) Do we have a better alternative? Any example? [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-simple-color Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[GSOC] Inclusion of external code
Hi, I want to keep definitions of pass through attrs of the components and render them. I see that current MyFaces keeps them in org.apache.myfaces.shared.renderkit.html.HTMLhttp://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HTML.java?view=markup . As project grows, content of this interface(or my own HTML5 interface) will get ugly, and I think Mojarra's approach[1][2] is better. Mojarra guys took this[1][2] stuff from probably Richfaces, and I want to use their approach in my project too. So, what is the possibility of inclusion of this code in my project? If possible, what do I need to do? I will request for permission from authors for using with Apache license, but is a private email like yes, you can use it enough? If not, I'll come with new stuff, which will use this approach. [1] http://www.docjar.com/html/api/com/sun/faces/renderkit/AttributeManager.java.html http://www.docjar.com/html/api/com/sun/faces/renderkit/AttributeManager.java.html [2] http://www.docjar.com/html/api/com/sun/faces/util/CollectionsUtils.java.html -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [GSOC] HTML5 Prototypes hx:inputText and hx:datalist
I think we could come up, later... with some convenience tags, like
hx:inputSearch / which has the most reasonable attrs.
Sure. That seems easy when we have hx:inputText.
Regarding the pattern attr, can't we drive something like:
pattern=[0-9][A-Z]{3} via the regEx validatior ?
Totally. That was the approach on other components, I missed this one.
Thanks.
Greetings,
Ali
On Wed, Jun 2, 2010 at 9:54 AM, Matthias Wessendorf mat...@apache.orgwrote:
I think we could come up, later... with some convenience tags, like
hx:inputSearch / which has the most reasonable attrs.
Regarding the pattern attr, can't we drive something like:
pattern=[0-9][A-Z]{3} via the regEx validatior ?
-Matthias
On Tue, Jun 1, 2010 at 1:04 PM, Ali Ok al...@aliok.com.tr wrote:
Hi,
These were first prototypes I sent to Matthias, and I think didn't send
it
to @dev.
For future reference: Wiki for hx:inputText and hx:datalist is
here:
https://cwiki.apache.org/confluence/display/MYFACES/GSoC+Html5+Prototypes+inputText+and+datalist
Regards,
Ali
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
Re: onclick,onmouseover etc. pass thru properties on h:outputText: MyFaces vs. Mojarra
Hi,
that's right, not there. It's a (very) simple component.
Some of the other components have this situation too, like:
* h:commandButton - align
* h:inputText - checked (doesn't make sense)
* ...
On the other hand, it does not cause big issues, other than blowing up the
markup, which is expected if you are specifying things like the above
attrs.
Yes, and I can say they are good and necessary :) But I wish they were
defined in some place.
The reason I asked this is, decision of using this approach in hx
components.
I understood that it would be better if I add solid fields for this kind
of attributes to expose at IDEs and taglib doc, since I don't have any spec
to follow :)
Thanks,
On Wed, Jun 2, 2010 at 9:51 AM, Matthias Wessendorf mat...@apache.orgwrote:
On Wed, Jun 2, 2010 at 1:18 AM, Ali Ok al...@aliok.com.tr wrote:
Hi,
I see onclick, onmouseover, etc. attributes of h:outputText are passed
thru and rendered.
For:
h:outputText id=... value=test onclick=alert('click'); .../
I got this with MyFaces 2:
span id=... onclick=alert('click'); test/span
However, Mojarra ignores 'onclick':
span id=... test/span
HtmlTextRenderer[0] of MyFaces, which extends HtmlTextRendererBase,
renders[1] pass thru attributes of HTML.COMMON_PASSTROUGH_ATTRIBUTES[2];
while Mojarra ignores onclick on h:outputText.
Is it OK to pass thru some attributes that are not defined in the spec?
since h:outputText is very simple (one reason why it is not a
ClientBehaviorHolder), it's correct
to ignore those attributes... I am actually surprised that something
like this is not triggered by the TCK
On the other hand, it does not cause big issues, other than blowing up
the markup, which is expected
if you are specifying things like the above attrs.
I couldn't find anything about onclick, onmouseover, etc. of
h:outputText
in
that's right, not there. It's a (very) simple component.
* JSF spec
* JSF Spec Facelet Taglib doc
:
https://javaserverfaces.dev.java.net/nonav/docs/2.0/vdldocs/facelets/h/outputText.html
* JSF Spec RenderKit
doc:
https://javaserverfaces.dev.java.net/nonav/docs/2.0/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Text.html
* JSF Spec
JavaDoc:
http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/javax/faces/component/html/HtmlOutputText.html
[0]
http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/renderkit/html/HtmlTextRenderer.java?view=markup
[1]
http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTextRendererBase.java?view=markup
line
127
[2]
http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HTML.java?view=markup
line
154
BTW, as you can see this is not something special to h:outputText. Most
components have this issue.
Regards,
Ali
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
Re: [GSOC-HTML5] Prototype hx:video, hx:mediaSource, hx:mediaSources
Here is the wiki:
https://cwiki.apache.org/confluence/display/MYFACES/GSoC+Html5+Prototypes+video%2C+audio%2C+mediaSource+and+mediaSources
On Wed, Jun 2, 2010 at 9:47 AM, Matthias Wessendorf mat...@apache.orgwrote:
+1 on the facet
-Matthias
PS: can you add this to the wiki as well ? ;-)
On Tue, Jun 1, 2010 at 9:11 PM, Ali Ok al...@aliok.com.tr wrote:
Hi again,
I couldn't settle the fallback stuff, so I want to discuss it again.
I noticed that a fallback facet may be better.
If HTML5 video[1] is not supported on a browser, it will ignore this
element
and render its children:
video
pYour browser does not support Html5 video! This text is ignored on
Html5 video enabled browsers and shown on not supported browsers./p
/video
Respectively, Html5 video enabled browsers will ignore the children of
video element (except source[2]).
And this look like a good use-case of facets to me.
If we limit fallback with two attributes, we will definitely restrict the
users in coming up with their own solutions. With
actionOnNoHTML5VideoSupport and loadAlternatePlayerAction
properties,
we're forcing user to write Javascript for playing the alternate video
player.
Let's say, we wrote some javascript function to activate alternate video
player: activateFlashPlayer()
Using attributes, our JSF XHTML will be something like:
script
function activateFlashPlayer(){
// run flash video player (player.swf is down below)
}
/script
...
hx:video loadAlternatePlayerAction=activateFlashPlayer()
...
embed player.swf ./embed
and, which may output an Html page like this:
script
function activateFlashPlayer(){
// run flash video player (player.swf below)
}
/script
...
video
script
activateFlashPlayer();
/script
/video
...
embed player.swf ./embed
On the other hand, using a facet, we'll have a JSF xhtml page like:
hx:video
f:facet name=falback
embed player.swf ./embed
/f:facet
/hx:video
which can output:
video
embed player.swf ./embed
/video
hx:video
= fallBack: does it need to be a facet ?
A late answer, but that's why I think it needs to be a facet :)
I don't like them much (find them not IDE-friendly), but what is the
disadvantage of facet here? Why do you avoid using that?
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-source-element
Thanks,
Ali
On Wed, May 26, 2010 at 3:42 PM, Matthias Wessendorf mat...@apache.org
wrote:
On Wed, May 26, 2010 at 2:38 PM, Ali Ok al...@aliok.com.tr wrote:
Hi Matthias,
I couldn't quite understand what you've meant.
Do you mean, (ignore the bad naming)
* having property named something like actionOnNoHTML5VideoSupport :
useFallBack | alert
* and having another property named something like
which can have the JS activation code for some
flash video player?
that's right
Or do you mean automatic fallback to flash video player?
nope :-)
I've done some
research about this before and I couldn't found any ASL or compatible
licensed flash video player to distrubute with the project (I haven't
done
too much research since this seems not practical to me). Assuming
there
is
one ASL-compatible flash video player somewhere, is it practical?
Regards,
Ali
On Wed, May 26, 2010 at 3:10 PM, Matthias Wessendorf
mat...@apache.org
wrote:
Hi Ali,
looks good so far.
One quick comment:
-hx:video
= fallBack: does it need to be a facet ?
What about alternatePlayer and warning (or alert) ?
-Matthias
On Wed, May 19, 2010 at 10:30 PM, Ali Ok al...@aliok.com.tr wrote:
Hi all,
I've prepared some component prototypes, and your feedback is
appreciated.
There are 20+ components and I want to send them to discuss
here, one
by
one; to have a 'cleaner' separation of the discussion.
Also, IMHO, it is better to post prototypes inline.
===
==hx:video
===
REFS:
[0]
http://www.whatwg.org/specs/web-apps/current-work/#video
[1] https://developer.mozilla.org/En/HTML/Element/Video
EXTENDS:
May extend a abstract component with hx:audio.
specific ATTRIBUTES:
preload can be:
none: do not preload the media from the server
metadata: fetch metadata (length, quality, etc.)
(default)
auto: load the data from the server, even if user
doesnt
play it
showControls:
true: browser's media controls are shown (default)
false: controls are not shown unless page author
provides
one
explicitly
[GSOC] HTML5 Prototype hx:inputDateTime and fx:validateDateRange
Hi, Here is the prototypes of these components: https://cwiki.apache.org/confluence/display/MYFACES/GSoC+Html5+Prototype+inputDateTime+and+validateDateRange -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [GSOC] HTML5 Prototype hx:inputDateTime and fx:validateDateRange
Hi, for validateDateRange, I'd prefer validateDateTimeRange as its name. I'd also take a look here: http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/tr_validateDateTimeRange.html Right. Looks like I mistyped that. @copy: note that we have a commons module, which could be the base for your converter/validator extensions. Ok. Thanks, Ali On Tue, Jun 1, 2010 at 12:16 PM, Matthias Wessendorf mat...@apache.orgwrote: for validateDateRange, I'd prefer validateDateTimeRange as its name. I'd also take a look here: http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/tr_validateDateTimeRange.html @copy: note that we have a commons module, which could be the base for your converter/validator extensions. On Tue, Jun 1, 2010 at 9:35 AM, Ali Ok al...@aliok.com.tr wrote: Hi, Here is the prototypes of these components: https://cwiki.apache.org/confluence/display/MYFACES/GSoC+Html5+Prototype+inputDateTime+and+validateDateRange -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[GSOC] HTML5 Prototypes hx:inputText and hx:datalist
Hi, These were first prototypes I sent to Matthias, and I think didn't send it to @dev. For future reference: Wiki for hx:inputText and hx:datalist is here: https://cwiki.apache.org/confluence/display/MYFACES/GSoC+Html5+Prototypes+inputText+and+datalist Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [GSOC-HTML5] Prototype hx:video, hx:mediaSource, hx:mediaSources
Hi again,
I couldn't settle the fallback stuff, so I want to discuss it again.
I noticed that a fallback *facet *may be better.
If HTML5 video[1] is not supported on a browser, it will ignore this element
and render its children:
video
pYour browser does not support Html5 video! This text is ignored on
Html5 video enabled browsers and shown on not supported browsers./p
/video
Respectively, Html5 video enabled browsers will ignore the children of
video element (except source[2]).
And this look like a good use-case of facets to me.
If we limit fallback with two attributes, we will definitely restrict the
users in coming up with their own solutions. With
actionOnNoHTML5VideoSupport and loadAlternatePlayerAction properties,
we're forcing user to write Javascript for playing the alternate video
player.
Let's say, we wrote some javascript function to activate alternate video
player: activateFlashPlayer()
Using attributes, our JSF XHTML will be something like:
script
function activateFlashPlayer(){
// run flash video player (player.swf is down below)
}
/script
...
hx:video *loadAlternatePlayerAction=**activateFlashPlayer()*
...
embed player.swf ./embed
and, which may output an Html page like this:
script
function activateFlashPlayer(){
// run flash video player (player.swf below)
}
/script
...
video
script
activateFlashPlayer();
/script
/video
...
embed player.swf ./embed
On the other hand, using a facet, we'll have a JSF xhtml page like:
hx:video
f:facet name=falback
embed player.swf ./embed
/f:facet
/hx:video
which can output:
video
embed player.swf ./embed
/video
hx:video
= fallBack: does it need to be a facet ?
A late answer, but that's why I think it needs to be a facet :)
I don't like them much (find them not IDE-friendly), but what is the
disadvantage of facet here? Why do you avoid using that?
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-source-element
Thanks,
Ali
On Wed, May 26, 2010 at 3:42 PM, Matthias Wessendorf mat...@apache.orgwrote:
On Wed, May 26, 2010 at 2:38 PM, Ali Ok al...@aliok.com.tr wrote:
Hi Matthias,
I couldn't quite understand what you've meant.
Do you mean, (ignore the bad naming)
* having property named something like actionOnNoHTML5VideoSupport :
useFallBack | alert
* and having another property named something like
which can have the JS activation code for some
flash video player?
that's right
Or do you mean automatic fallback to flash video player?
nope :-)
I've done some
research about this before and I couldn't found any ASL or compatible
licensed flash video player to distrubute with the project (I haven't
done
too much research since this seems not practical to me). Assuming there
is
one ASL-compatible flash video player somewhere, is it practical?
Regards,
Ali
On Wed, May 26, 2010 at 3:10 PM, Matthias Wessendorf mat...@apache.org
wrote:
Hi Ali,
looks good so far.
One quick comment:
-hx:video
= fallBack: does it need to be a facet ?
What about alternatePlayer and warning (or alert) ?
-Matthias
On Wed, May 19, 2010 at 10:30 PM, Ali Ok al...@aliok.com.tr wrote:
Hi all,
I've prepared some component prototypes, and your feedback is
appreciated.
There are 20+ components and I want to send them to discuss here, one
by
one; to have a 'cleaner' separation of the discussion.
Also, IMHO, it is better to post prototypes inline.
===
==hx:video
===
REFS:
[0] http://www.whatwg.org/specs/web-apps/current-work/#video
[1] https://developer.mozilla.org/En/HTML/Element/Video
EXTENDS:
May extend a abstract component with hx:audio.
specific ATTRIBUTES:
preload can be:
none: do not preload the media from the server
metadata: fetch metadata (length, quality, etc.) (default)
auto: load the data from the server, even if user doesnt
play it
showControls:
true: browser's media controls are shown (default)
false: controls are not shown unless page author provides
one
explicitly
loop:
true or false (default)
poster:
image to show when not playing or seeking
width:
width of the video
height:
height of the video
FACETS:
fallBack:
content to display when HTML5 video is not supported.
possible
actions
can be using a flash player as a fallback or displaying a
message that displays this is not supported.
NOTES:
see hx:mediaSource
onclick,onmouseover etc. pass thru properties on h:outputText: MyFaces vs. Mojarra
Hi,
I see onclick, onmouseover, etc. attributes of h:outputText are passed
thru and rendered.
For:
h:outputText id=... value=test onclick=alert('click'); .../
I got this with MyFaces 2:
span id=... *onclick=alert('click');* test/span
However, Mojarra ignores 'onclick':
span id=... test/span
HtmlTextRenderer[0] of MyFaces, which extends HtmlTextRendererBase,
renders[1] pass thru attributes of HTML.COMMON_PASSTROUGH_ATTRIBUTES[2];
while Mojarra ignores onclick on h:outputText.
Is it OK to pass thru some attributes that are not defined in the spec?
I couldn't find anything about onclick, onmouseover, etc. of h:outputText
in
* JSF spec
* JSF Spec Facelet Taglib doc :
https://javaserverfaces.dev.java.net/nonav/docs/2.0/vdldocs/facelets/h/outputText.html
* JSF Spec RenderKit doc:
https://javaserverfaces.dev.java.net/nonav/docs/2.0/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Text.html
* JSF Spec JavaDoc:
http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/javax/faces/component/html/HtmlOutputText.html
[0]
http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/renderkit/html/HtmlTextRenderer.java?view=markup
[1]
http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTextRendererBase.java?view=markup
line
127
[2]
http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HTML.java?view=markup
line
154
BTW, as you can see this is not something special to h:outputText. Most
components have this issue.
Regards,
Ali
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
[GSOC] HTML5 Prototype hx:inputFileUpload
Hi all, Here is the wiki https://cwiki.apache.org/confluence/display/MYFACES/GSoC+HTML5+inputFileUpload+Prototype about hx:inputFileUpload. Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [GSOC] HTML5 Prototype hx:inputNumber
would be cool if there would be some client-side validation hook,
instead of just server-side
?
HTML5 input element's min and max attributes are there for it. Form won't
be submitted and a warning will be displayed if value is not between
min-max. This validation is provided by the browser (just Opera yet).
A validation with same min-max will be done on server side too.
However, the logic should be driven by a JSF validator.
Ok, code below seems clear:
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - -- --
hx:inputNumberSlider value=#{someBean.someNumberField}
*fx*:validateNumberRange maximum=1000 minimum=100 / *!-- New
validator --*
/hx:inputNumberSlider
!-- expected HTML5 code --
input type=range value= min=100 step=9 max=1000 /
This can do both server-side validation and client-side validation of
input(basically rendering min and max attributes). max and min
attributes can be set by validator on its facelet handler, thus no need to
iterate on children on parent.
But, what about this:
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - -- --
hx:inputNumberSlider value=#{someBean.someNumberField}
*f:*validateLongRange maximum=1000 minimum=100 / *!-- JSF Core
validator--*
/hx:inputNumberSlider
!-- expected HTML5 code --
input type=range value= min=100 step=9 max=1000 /
If we support this, in order to render min and max attributes of input
element, hx:inputNumberSlider will get those values from its attached
validators.
I would not like parent iterating on validators and looking for certain
types of validators.
Another way to achieve this?
Thanks,
Ali
On Thu, May 27, 2010 at 4:53 PM, Matthias Wessendorf mat...@apache.orgwrote:
On Thu, May 27, 2010 at 2:07 PM, Ali Ok al...@aliok.com.tr wrote:
Hi,
why not breaking this into two components ?
hx:inputNumberSpinner and hx:inputNumberSlider
Ok. My initial prototypes were separate already on my workspace.
the min/max should be driven by a range validator component
Then I am removing min and max properties from the component(s).
it is fine to have maximum/minimum on the component itself. However,
the logic should be driven by a JSF validator.
would be cool if there would be some client-side validation hook,
instead of just
server-side
Or, another alternative, should we keep them and allow overriding by a
range
validator? At the initial prototype, an implicit validator will be
attached
with the values of min and max. So, may be we can keep them and if an
explicit validator is not set, implicit one can be attached.
Just an alternative idea, IMHO, removing min and max is better :)
Thanks,
Ali
On Thu, May 27, 2010 at 2:49 PM, Bruno Aranda brunoara...@gmail.com
wrote:
+1 I agree with Matthias.
Thanks!
Bruno
On 27 May 2010 12:44, Matthias Wessendorf mat...@apache.org wrote:
Hi,
why not breaking this into two components ?
hx:inputNumberSpinner and hx:inputNumberSlider
the min/max should be driven by a range validator component
-Matthias
On Thu, May 27, 2010 at 1:11 PM, Ali Ok al...@aliok.com.tr wrote:
Hi,
This is hx:inputNumber, which can render a spinner or a slider.
It may seem so straight forward, but here is the prototype.
===
==hx:inputNumber==
===
REFS:
[0]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#range-state
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state
[3]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary
EXTENDS:
some input component
ATTRIBUTES not present in ancestor:
type(required): can be
'spinner': which renders a spinner text box
'slider': which renders a slider
suggestions: same suggestion mechanism with hx:inputText
min: minimum value that can be selected. default to 0.
max: maximum that can be selected. default to 100.
step: gap between each segment. if both 'step' and 'segmentCount' is
not
defined, 'step' is default to (max-min)/(100).
segmentCount: used to calculate step with min and max. step ~=
(max-min)/segmentCount. default to 100, if step is not defined too.
either 'step' or 'segmentCount' should be defined, not both!
autocomplete: to override owner form's autocomplete attribute for its
children. can be 'on' 'off' 'default'(default)
datalist: id of hx:datalist for suggestions mechanism. by this way,
suggestion options(datalist) can be shared across several input
elements.
NOTES:
Cannot extend hx:inputText, since this doesn't have size attribute!
Will
extend an abstract middle component.
--
!-- - - - - - - - - -usage
Re: [GSOC] HTML5 Prototype hx:inputNumber
Hi,
Got it, thanks for the reply.
Interesting: since (I think) min/max is poor, I am wondering why they
weren't naming it minimum/maximum :-)
Wait until you see HTML5 DnD, which is disaster :)
Greetings,
Ali
On Fri, May 28, 2010 at 11:01 AM, Matthias Wessendorf mat...@apache.orgwrote:
On Fri, May 28, 2010 at 9:49 AM, Ali Ok al...@aliok.com.tr wrote:
would be cool if there would be some client-side validation hook,
instead of just server-side
?
HTML5 input element's min and max attributes are there for it. Form
won't
be submitted and a warning will be displayed if value is not between
min-max. This validation is provided by the browser (just Opera yet).
I was wondering if the default looks OK (at least for the beginning), I
guess
we are fine with that. thx
A validation with same min-max will be done on server side too.
yes, with a JSF validatior
However, the logic should be driven by a JSF validator.
Ok, code below seems clear:
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - --
--
hx:inputNumberSlider value=#{someBean.someNumberField}
fx:validateNumberRange maximum=1000 minimum=100 / !-- New
validator
--
/hx:inputNumberSlider
why do we need a new validatior ? why would validateDoubleRange not work
?
!-- expected HTML5 code --
input type=range value= min=100 step=9 max=1000 /
the renderer can check if the validateDoubleRange is present and
simple render out those attrs.
Interesting: since (I think) min/max is poor, I am wondering why they
weren't naming it minimum/maximum :-)
This can do both server-side validation and client-side validation of
input(basically rendering min and max attributes). max and min
attributes can be set by validator on its facelet handler, thus no need
to
iterate on children on parent.
But, what about this:
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - --
--
hx:inputNumberSlider value=#{someBean.someNumberField}
f:validateLongRange maximum=1000 minimum=100 / !-- JSF Core
validator--
/hx:inputNumberSlider
!-- expected HTML5 code --
input type=range value= min=100 step=9 max=1000 /
If we support this, in order to render min and max attributes of input
element, hx:inputNumberSlider will get those values from its attached
validators.
I would not like parent iterating on validators and looking for certain
types of validators.
Another way to achieve this?
nope, go by the renderer of the input...
-Matthias
Thanks,
Ali
On Thu, May 27, 2010 at 4:53 PM, Matthias Wessendorf mat...@apache.org
wrote:
On Thu, May 27, 2010 at 2:07 PM, Ali Ok al...@aliok.com.tr wrote:
Hi,
why not breaking this into two components ?
hx:inputNumberSpinner and hx:inputNumberSlider
Ok. My initial prototypes were separate already on my workspace.
the min/max should be driven by a range validator component
Then I am removing min and max properties from the component(s).
it is fine to have maximum/minimum on the component itself. However,
the logic should be driven by a JSF validator.
would be cool if there would be some client-side validation hook,
instead of just
server-side
Or, another alternative, should we keep them and allow overriding by a
range
validator? At the initial prototype, an implicit validator will be
attached
with the values of min and max. So, may be we can keep them and if an
explicit validator is not set, implicit one can be attached.
Just an alternative idea, IMHO, removing min and max is better :)
Thanks,
Ali
On Thu, May 27, 2010 at 2:49 PM, Bruno Aranda brunoara...@gmail.com
wrote:
+1 I agree with Matthias.
Thanks!
Bruno
On 27 May 2010 12:44, Matthias Wessendorf mat...@apache.org wrote:
Hi,
why not breaking this into two components ?
hx:inputNumberSpinner and hx:inputNumberSlider
the min/max should be driven by a range validator component
-Matthias
On Thu, May 27, 2010 at 1:11 PM, Ali Ok al...@aliok.com.tr wrote:
Hi,
This is hx:inputNumber, which can render a spinner or a slider.
It may seem so straight forward, but here is the prototype.
===
==hx:inputNumber==
===
REFS:
[0]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#range-state
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state
[3]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary
EXTENDS:
some input component
ATTRIBUTES not present in ancestor:
type(required): can be
'spinner': which renders a spinner text box
'slider': which
Re: [GSOC] HTML5 Prototypes DnD components
Inline stuff don't seem good. So, here is the complete content: http://pastebin.com/PmiDF4UB , and only Javascript part: http://pastebin.com/CG3WtdLw Please don't care about namespace and syntax of Javascript please. Those will be extracted into some .js file and will be improved.
Re: [GSOC] HTML5 Prototypes DnD components
Ok, I will put these on a cwiki page. But please not that these are not publish-quality stuff, they are just for getting your feedback. We'll not need them after 3 month GSoC period, we'll have example application, Javadoc, Tlddoc and some wiki (and a presentation hopefully). So just for better readability, I can put them. On Fri, May 28, 2010 at 7:04 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Ali, +1 on putting this on a cwiki space - it will be more readable! Regards, Jakob 2010/5/28 Matthias Wessendorf mat...@apache.org Hi Ali, a very few comments, after a first quick look: = I think I prefer dropTarger over 'dropZone' -Another example may be dropping files from your desktop, but what to do with them? We'll have hx:inputFileUpload for DnD file uploading. = that's an interesting idea, IMO worth to investigate here = exactly sure yet about the mimetype things... * hx:panel = please no dependency to Tomahawk ;-) For the JS, I think we should do some namespacing ;-) (yeah I saw your comment) Question: Do you mind to publish all the documentation to the new cwiki space? I think that will be easier for future overhauls of these pages/prototypes. -Matthias On Fri, May 28, 2010 at 3:16 PM, Ali Ok al...@aliok.com.tr wrote: Hi all, I've prepared DnD related protoypes. We'll have fx:dragSource fx:dropZone behaviors and hx:Panel for wrapping non-draggable components (like h:panelGrid). Since these are complex enough for prototyping, I passed drag image concept. We can think about it later. Don't care about namespace and syntax of Javascript please. Those will be extracted into some .js file. Here is what other component libraries handle this: http://www.primefaces.org:8080/prime-showcase/ui/draggableBasic.jsf http://www.primefaces.org:8080/prime-showcase/ui/droppableBarca.jsf http://component-showcase.icefaces.org/component-showcase/showcase.iface http://download.oracle.com/docs/cd/E15523_01/apirefs./e12419/toc.htm#DragDrop http://livedemo.exadel.com/richfaces-demo/richfaces/dragSupport.jsf === ==fx:dragSource== === REFS: [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dnd [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data [2] https://developer.mozilla.org/En/DragDrop/Drag_and_Drop [3] https://developer.mozilla.org/En/DragDrop/DataTransfer [4] https://developer.mozilla.org/En/DragDrop/Recommended_Drag_Types [5] https://developer.mozilla.org/En/DragDrop/Drag_Operations EXTENDS: ClientBehavior ATTRIBUTES: action (required): Allowed DnD drag action from this source. Can be comma separated set or String[] or CollectionString of copy, copyLink, copyMove, link, linkMove, move, all. dropZoneTypes (optional): With this property, we can specify which types of drop zones we can make DnD from this source. Can be comma separated set or String[] or CollectionString param(optional): Parameter to be sent to server when drop operation is done. NOTES: May use custom non-visible data [1], data-* when at least one browser starts supporting it === ==fx:dropZone === REFS: [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dnd [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data [2] http://html5demos.com/drag-anything [3] http://apirocks.com/html5/html5.html#slide13 [4] https://developer.mozilla.org/En/DragDrop/Drag_and_Drop [5] https://developer.mozilla.org/En/DragDrop/DataTransfer [6] https://developer.mozilla.org/En/DragDrop/Recommended_Drag_Types [7] https://developer.mozilla.org/En/DragDrop/Drag_Operations EXTENDS: AjaxBehavior ATTRIBUTES: actions (required): Allowed DnD actions. Can be comma separated set or String[] or CollectionString of copy, copyLink, copyMove, link, linkMove, move, all. If action of dragEvent are not one of these, DnD will stop. dropListener (required): Listener method to handle DnD operation on server side. rerender (optional): same with f:ajax rerender attribute. types (optional): Used in conjunction with fx:dragSource's dropZoneTypes attribute. Types of this dropZone. Can be comma separated set or String[] or CollectionString
Re: [GSOC] HTML5 Prototypes DnD components
Hi, Here is the wiki page: https://cwiki.apache.org/confluence/display/MYFACES/GSoC+HTML5+DnD+Prototypes https://cwiki.apache.org/confluence/display/MYFACES/GSoC+HTML5+DnD+PrototypesI will put new prototypes there. To remind again: Don't care about namespace and syntax of Javascript please. Those will be optimized and extracted into some .js file. Regards, Ali On Fri, May 28, 2010 at 10:38 PM, Matthias Wessendorf mat...@apache.orgwrote: +1 sent from my Android phone Am 28.05.2010 21:20 schrieb Jakob Korherr jakob.korh...@gmail.com: Yes, right. I am really looking forward to all this stuff. Sounds just great :) 2010/5/28 Ali Ok al...@aliok.com.tr Ok, I will put these on a cwiki page. But please not that these are not publish-quality stuff... -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: htt... -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[GSOC] HTML5 Prototype hx:inputNumber
Hi,
This is hx:inputNumber, which can render a spinner or a slider.
It may seem so straight forward, but here is the prototype.
===
==hx:inputNumber==
===
REFS:
[0]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#range-state
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state
[3]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary
EXTENDS:
some input component
ATTRIBUTES not present in ancestor:
type(required): can be
'spinner': which renders a spinner text box
'slider': which renders a slider
suggestions: *same suggestion mechanism with hx:inputText*
min: minimum value that can be selected. default to 0.
max: maximum that can be selected. default to 100.
step: gap between each segment. if both 'step' and 'segmentCount' is not
defined, 'step' is default to (max-min)/(100).
segmentCount: used to calculate step with min and max. step ~=
(max-min)/segmentCount. default to 100, if step is not defined too.
either 'step' or 'segmentCount' should be defined, not both!
autocomplete: to override owner form's autocomplete attribute for its
children. can be 'on' 'off' 'default'(default)
datalist: id of hx:datalist for suggestions mechanism. by this way,
suggestion options(datalist) can be shared across several input elements.
NOTES:
Cannot extend hx:inputText, since this doesn't have size attribute! Will
extend an abstract middle component.
--
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - -- --
hx:inputNumber type=spinner value=#{someBean.someNumberField}
min=100 max=1000/
!-- expected HTML5 code --
input type=number value= min=100 step=9 max=1000 /
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - -- --
hx:inputNumber type=slider value=#{someBean.someNumberField} min=100
max=1000 segmentCount=10/
!-- expected HTML5 code --
input type=range value= min=100 step=90 max=1000 /
Regards,
Ali
[GSOC] HTML5 Prototype hx:inputColor and hx:inputEmail
Hi,
I am posting 2 prototypes inline, since they seem easy convenience tags.
===
==hx:inputColor=
===
REFS:
[0]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#color-state
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary
EXTENDS:
h:inputText
ATTRIBUTES not present in ancestor:
suggestions: same suggestion mechanism with hx:inputText
autocomplete: to override owner form's autocomplete attribute for its
children. can be 'on' 'off' 'default'(default)
NOTES:
Cannot extend hx:inputText, since this doesn't have
size,pattern,placeholder, etc. attributes! Will create an abstract middle
component.
No browser support for this yet!
For suggestions and more, see hx:inputText usage.
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - -- --
hx:inputColor value=#{someBean.someField} /
!-- expected HTML5 code --
input type=color value= /
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - -- --
hx:inputRange value=#{someBean.someField} suggestions=#00,
#FF/
!-- expected HTML5 code --
input list=idOfDataList type=color /
datalist id=idOfDataList
option value=#00 label=#00 /
option value=#FF label=#FF /
/datalist
===
==hx:inputEmail==
===
REFS:
[0]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#e-mail-state
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary
EXTENDS:
hx:inputText
ATTRIBUTES not present in ancestor:
multiple: email input type supports 'multiple' attribute. can be used with
datalist(suggestions). default to 'false'.
see:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-multiple
NOTES:
About 'pattern': browsers should make the email validation. this attribute
can be used for extra validation.
For suggestions and more, see hx:inputText usage.
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - -- --
hx:inputEmail value=#{someBean.email} suggestions=em...@example.org,
anotherem...@example.org/
!-- expected HTML5 code--
input type=email value= list=idOfDataList/
datalist id=idOfDataList
option value=em...@example.org label=em...@example.org /
option value=anotherem...@example.org label=anotherem...@example.org /
/datalist
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - -- --
hx:inputEmail value=#{someBean.email}
suggestions=#{someBean.emailSuggestions} multiple=true/
!-- expected HTML5 code--
input type=email value= list=idOfDataList/
datalist id=idOfDataList
option value=em...@example.org label=Email 1 /
option value=anotherem...@example.org label=Email 2 /
option value=theotherem...@example.org label=Email 3 /
/datalist
Thanks for feedback,
Ali
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
Re: [GSOC] HTML5 Prototype hx:inputNumber
Hi,
why not breaking this into two components ?
hx:inputNumberSpinner and hx:inputNumberSlider
Ok. My initial prototypes were separate already on my workspace.
the min/max should be driven by a range validator component
Then I am removing min and max properties from the component(s).
Or, another alternative, should we keep them and allow overriding by a range
validator? At the initial prototype, an implicit validator will be attached
with the values of min and max. So, may be we can keep them and if an
explicit validator is not set, implicit one can be attached.
Just an alternative idea, IMHO, removing min and max is better :)
Thanks,
Ali
On Thu, May 27, 2010 at 2:49 PM, Bruno Aranda brunoara...@gmail.com wrote:
+1 I agree with Matthias.
Thanks!
Bruno
On 27 May 2010 12:44, Matthias Wessendorf mat...@apache.org wrote:
Hi,
why not breaking this into two components ?
hx:inputNumberSpinner and hx:inputNumberSlider
the min/max should be driven by a range validator component
-Matthias
On Thu, May 27, 2010 at 1:11 PM, Ali Ok al...@aliok.com.tr wrote:
Hi,
This is hx:inputNumber, which can render a spinner or a slider.
It may seem so straight forward, but here is the prototype.
===
==hx:inputNumber==
===
REFS:
[0]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#range-state
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state
[3]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary
EXTENDS:
some input component
ATTRIBUTES not present in ancestor:
type(required): can be
'spinner': which renders a spinner text box
'slider': which renders a slider
suggestions: same suggestion mechanism with hx:inputText
min: minimum value that can be selected. default to 0.
max: maximum that can be selected. default to 100.
step: gap between each segment. if both 'step' and 'segmentCount' is not
defined, 'step' is default to (max-min)/(100).
segmentCount: used to calculate step with min and max. step ~=
(max-min)/segmentCount. default to 100, if step is not defined too.
either 'step' or 'segmentCount' should be defined, not both!
autocomplete: to override owner form's autocomplete attribute for its
children. can be 'on' 'off' 'default'(default)
datalist: id of hx:datalist for suggestions mechanism. by this way,
suggestion options(datalist) can be shared across several input
elements.
NOTES:
Cannot extend hx:inputText, since this doesn't have size attribute! Will
extend an abstract middle component.
--
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - --
--
hx:inputNumber type=spinner value=#{someBean.someNumberField}
min=100 max=1000/
!-- expected HTML5 code --
input type=number value= min=100 step=9 max=1000 /
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - --
--
hx:inputNumber type=slider value=#{someBean.someNumberField}
min=100
max=1000 segmentCount=10/
!-- expected HTML5 code --
input type=range value= min=100 step=90 max=1000 /
Regards,
Ali
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
Re: [GSOC] HTML5 Prototype hx:inputColor and hx:inputEmail
hx:inputRange value=#{someBean.someField} suggestions=#00,
#FF/
Copy-paste mistake, sorry :)
It should be hx:inputColor as in the first usecase:
hx:inputColor value=#{someBean.someField} /
and
hx:inputColor value=#{someBean.someField} suggestions=#00,
#FF/
Q: the validation of a correct email pattern is driven by the
user-agent, right?
Right. And an email validator will be attached on the server-side too.
On Thu, May 27, 2010 at 2:49 PM, Matthias Wessendorf mat...@apache.orgwrote:
On Thu, May 27, 2010 at 1:25 PM, Ali Ok al...@aliok.com.tr wrote:
Hi,
I am posting 2 prototypes inline, since they seem easy convenience tags.
===
==hx:inputColor=
===
REFS:
[0]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#color-state
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary
EXTENDS:
h:inputText
ATTRIBUTES not present in ancestor:
suggestions: same suggestion mechanism with hx:inputText
autocomplete: to override owner form's autocomplete attribute for its
children. can be 'on' 'off' 'default'(default)
NOTES:
Cannot extend hx:inputText, since this doesn't have
size,pattern,placeholder, etc. attributes! Will create an abstract middle
component.
No browser support for this yet!
For suggestions and more, see hx:inputText usage.
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - --
--
hx:inputColor value=#{someBean.someField} /
!-- expected HTML5 code --
input type=color value= /
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - --
--
hx:inputRange value=#{someBean.someField} suggestions=#00,
#FF/
!-- expected HTML5 code --
input list=idOfDataList type=color /
datalist id=idOfDataList
option value=#00 label=#00 /
option value=#FF label=#FF /
/datalist
Not sure why some generic word like range make the compont turn into
a color range selector; I guess that's not too clear :-)
range can be different, see adf faces' sliders (number and range)
===
==hx:inputEmail==
===
REFS:
[0]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#e-mail-state
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary
EXTENDS:
hx:inputText
ATTRIBUTES not present in ancestor:
multiple: email input type supports 'multiple' attribute. can be used
with
datalist(suggestions). default to 'false'.
see:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-multiple
NOTES:
About 'pattern': browsers should make the email validation. this
attribute
can be used for extra validation.
For suggestions and more, see hx:inputText usage.
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - --
--
hx:inputEmail value=#{someBean.email} suggestions=em...@example.org,
anotherem...@example.org/
!-- expected HTML5 code--
input type=email value= list=idOfDataList/
datalist id=idOfDataList
option value=em...@example.org label=em...@example.org /
option value=anotherem...@example.org label=anotherem...@example.org
/
/datalist
!-- - - - - - - - - -usage- - - - - - - - - - - - - - - - - - - - --
--
hx:inputEmail value=#{someBean.email}
suggestions=#{someBean.emailSuggestions} multiple=true/
!-- expected HTML5 code--
input type=email value= list=idOfDataList/
datalist id=idOfDataList
option value=em...@example.org label=Email 1 /
option value=anotherem...@example.org label=Email 2 /
option value=theotherem...@example.org label=Email 3 /
/datalist
looks good, so far.
Q: the validation of a correct email pattern is driven by the
user-agent, right?
-M
Thanks for feedback,
Ali
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
Re: [GSOC-HTML5] Prototype hx:video, hx:mediaSource, hx:mediaSources
Hi Matthias,
I couldn't quite understand what you've meant.
Do you mean, (ignore the bad naming)
* having property named something like actionOnNoHTML5VideoSupport :
useFallBack | alert
* and having another property named something like
loadAlternatePlayerAction which can have the JS activation code for some
flash video player?
Or do you mean automatic fallback to flash video player? I've done some
research about this before and I couldn't found any ASL or compatible
licensed flash video player to distrubute with the project (I haven't done
too much research since this seems not practical to me). Assuming there is
one ASL-compatible flash video player somewhere, is it practical?
Regards,
Ali
On Wed, May 26, 2010 at 3:10 PM, Matthias Wessendorf mat...@apache.orgwrote:
Hi Ali,
looks good so far.
One quick comment:
-hx:video
= fallBack: does it need to be a facet ?
What about alternatePlayer and warning (or alert) ?
-Matthias
On Wed, May 19, 2010 at 10:30 PM, Ali Ok al...@aliok.com.tr wrote:
Hi all,
I've prepared some component prototypes, and your feedback is
appreciated.
There are 20+ components and I want to send them to discuss here, one by
one; to have a 'cleaner' separation of the discussion.
Also, IMHO, it is better to post prototypes inline.
===
==hx:video
===
REFS:
[0] http://www.whatwg.org/specs/web-apps/current-work/#video
[1] https://developer.mozilla.org/En/HTML/Element/Video
EXTENDS:
May extend a abstract component with hx:audio.
specific ATTRIBUTES:
preload can be:
none: do not preload the media from the server
metadata: fetch metadata (length, quality, etc.) (default)
auto: load the data from the server, even if user doesnt play
it
showControls:
true: browser's media controls are shown (default)
false: controls are not shown unless page author provides one
explicitly
loop:
true or false (default)
poster:
image to show when not playing or seeking
width:
width of the video
height:
height of the video
FACETS:
fallBack:
content to display when HTML5 video is not supported.
possible
actions
can be using a flash player as a fallback or displaying a
message that displays this is not supported.
NOTES:
see hx:mediaSource and hx:mediaSources
new track feature is not included, since there is no browser
support yet (impossible to test). this feature can be added
when a browser starts supporting it
!-- ---usage
--- --
hx:video value=#{videoBean.someVideoFileURL} preload=metadata
poster=somePosterImage.jpg
width=600px height=300px
autoplay=true loop=true showControls=true
f:facet name=fallBack
embed player.swf ./embed
!-- SOME FALLBACK MECHANISM TO PLAY THE FILE (FLASH may be). or
alerting the user about HTML5 video support. --
/f:facet
/hx:video
!-- expected HTML5 code --
video src=someAddress/someFile.mkv preload=metadata autoplay loop
controls poster=somePosterImage.jpg
width=600px height=300px
embed player.swf ./embed
/video
!-- ---usage
--- --
hx:video preload=none
autoplay=false loop=false showControls=false
poster=#{videoBean.posterImage}
f:facet name=fallBack
Your browser does not support HTML5 video.
/f:facet
hx:mediaSource src=http://someaddress/someFile.ogg;
contentType=video/ogg codecs=avc1.42E01E media=screen and
(device-width: 800px)
hx:mediaSource src=http://someaddress/some3DFile.ogg;
media=3d-glasses
!-- hx:mediaSources component, not hx:mediaSource --
hx:mediaSources items=#{someBean.mediaInfoList}
/hx:video
!-- expected HTML5 code for usage --
video preload=none poster=somePosterImage.jpg controls=false
autoplay=false
Your browser does not support HTML5 video.
source src='http://someaddress/someFile.ogg' Type='video/ogg;
codecs=avc1.42E01E' media=screen and (device-width: 800px) /
source src='someAddress/some3Dfile.ogg' media=3d-glasses/
!-- elements below are generated with hx:mediaSources --
source src='video.mp4' type='video/mp4; codecs=avc1.42E01E,
mp4a.40.2' media=screen
source src='video.mp4' type='video/mp4; codecs=avc1.58A01E,
mp4a.40.2' media=3d-glasses
source src='video.mp4' type='video/mp4; codecs=avc1.4D401E,
mp4a
[GSOC-HTML5] Prototype hx:video, hx:mediaSource, hx:mediaSources
Hi all,
I've prepared some component prototypes, and your feedback is appreciated.
There are 20+ components and I want to send them to discuss here, one by
one; to have a 'cleaner' separation of the discussion.
Also, IMHO, it is better to post prototypes inline.
*=**===**===***
*==hx:video*
*===*
REFS:
[0] http://www.whatwg.org/specs/web-apps/current-work/#video
[1] https://developer.mozilla.org/En/HTML/Element/Video
EXTENDS:
May extend a abstract component with hx:audio.
specific ATTRIBUTES:
preload can be:
none: do not preload the media from the server
metadata: fetch metadata (length, quality, etc.) (default)
auto: load the data from the server, even if user doesnt play it
showControls:
true: browser's media controls are shown (default)
false: controls are not shown unless page author provides one
explicitly
loop:
true or false (default)
poster:
image to show when not playing or seeking
width:
width of the video
height:
height of the video
FACETS:
fallBack:
content to display when HTML5 video is not supported. possible
actions
can be using a flash player as a fallback or displaying a
message that displays this is not supported.
NOTES:
see hx:mediaSource and hx:mediaSources
new track feature is not included, since there is no browser
support yet (impossible to test). this feature can be added
when a browser starts supporting it
!-- ---usage
--- --
hx:video value=#{videoBean.someVideoFileURL} preload=metadata
poster=somePosterImage.jpg
width=600px height=300px
autoplay=true loop=true showControls=true
f:facet name=fallBack
embed player.swf ./embed
!-- SOME FALLBACK MECHANISM TO PLAY THE FILE (FLASH may be). or
alerting the user about HTML5 video support. --
/f:facet
/hx:video
!-- expected HTML5 code --
video src=someAddress/someFile.mkv preload=metadata autoplay loop
controls poster=somePosterImage.jpg
width=600px height=300px
embed player.swf ./embed
/video
!-- ---usage
--- --
hx:video preload=none
autoplay=false loop=false showControls=false
poster=#{videoBean.posterImage}
f:facet name=fallBack
Your browser does not support HTML5 video.
/f:facet
hx:mediaSource src=http://someaddress/someFile.ogg;
contentType=video/ogg codecs=avc1.42E01E media=screen and
(device-width: 800px)
hx:mediaSource src=http://someaddress/some3DFile.ogg;
media=3d-glasses
!-- hx:mediaSources component, not hx:mediaSource --
hx:mediaSources items=#{someBean.mediaInfoList}
/hx:video
!-- expected HTML5 code for usage --
video preload=none poster=somePosterImage.jpg controls=false
autoplay=false
Your browser does not support HTML5 video.
source src='http://someaddress/someFile.ogg' Type='video/ogg;
codecs=avc1.42E01E' media=screen and (device-width: 800px) /
source src='someAddress/some3Dfile.ogg' media=3d-glasses/
!-- elements below are generated with hx:mediaSources --
source src='video.mp4' type='video/mp4; codecs=avc1.42E01E,
mp4a.40.2' media=screen
source src='video.mp4' type='video/mp4; codecs=avc1.58A01E,
mp4a.40.2' media=3d-glasses
source src='video.mp4' type='video/mp4; codecs=avc1.4D401E,
mp4a.40.2'
source src='video.mp4' type='video/mp4; codecs=avc1.64001E,
mp4a.40.2'
source src='video.mp4' type='video/mp4; codecs=mp4v.20.8,
mp4a.40.2'
/video
*===**===**===**==*
*===hx:mediaSource=*
*===*
REFS:
[0]
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-source-element
[1] https://developer.mozilla.org/En/HTML/Element/Source
EXTENDS:
--
specific ATTRIBUTES:
src:
URL of the source.
contentType:
MIME content type of the source (ie:video/ogg).
codecs:
Codecs of the source (ie:'avc1.64001E, mp4a.40.2').
media:
media attribute: just like the @media in CSS.
NOTES:
see hx:mediaSources, hx:audio and hx:video
!-- ---usage --
hx:mediaSource src=http://someaddress/someFile.ogg;
contentType=video/ogg codecs=avc1.42E01E media=screen and
(device-width: 800px)/
!-- expected HTML5 code for usage--
source src='http://someaddress/someFile.ogg' contentType=video/ogg
codecs=avc1.42E01E
Re: [GSOC-HTML5] ClientBehavior and ClientBehaviorHolder's attributes
Hi Jakob, Sine these things are new in HTML5 it is normal that you have to change stuff on MyFaces in order to integrate it perfectly. The best you can do here is (as we already discussed some time ago) a special init parameter to enable/disable this stuff. Right... Thanks for the reply and ideas, Ali On Mon, May 17, 2010 at 9:20 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Ali, Just a shot into the blue, but I think the following might work: In ClientBehavior.getScript(ClientBehaviorContext behaviorContext) you can use behaviorContext.getComponent() and use getAttributes().put(draggable, true);. However draggable is not a standard bypass attribute and thus MyFaces won't render it, so you'd have to change this stuff on MyFaces. About the thing with ondragstart and ondragend: You can do it, but again you will have to change stuff on MyFaces. See org.apache.myfaces.shared.renderkit.ClientBehaviorEvents and HtmlRendererUtils.renderBehaviorizedEventHandlers() for details. Sine these things are new in HTML5 it is normal that you have to change stuff on MyFaces in order to integrate it perfectly. The best you can do here is (as we already discussed some time ago) a special init parameter to enable/disable this stuff. I hope this helps you in some kind of way. Regards, Jakob 2010/5/15 Ali Ok al...@aliok.com.tr At the components that I cannot modify, things got worse. I can never set draggable=true on them: h:inputText fx:dragSupportClientBehavior .../ /h:inputText Ignore these 2 sentences, since I can't set 'ondragstart' and 'ondragend' on h:inputText using a ClientBehavior anyway :) On Sat, May 15, 2010 at 3:02 AM, Ali Ok al...@aliok.com.tr wrote: At the components that I cannot modify, things got worse. I can never set draggable=true on them: h:inputText fx:dragSupportClientBehavior .../ /h:inputText -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Tag handler for custom Behavior (not ClientBehavior)
Hi,
I was playing with JSF2 behaviors and I wrote a new behavior (not
ClientBehavior). Problem I described here doesn't seem like a impl bug,
instead it seems like a missing thing in the spec to me.
Let me explain my structure first. I have two abstract stuff in
Behavior-side:
- ByPassAttributeBehavior
@FacesBehavior(value = org.apache.myfaces.html5.ByPassAttributeBehavior)
public class ByPassAttributeBehavior extends *BehaviorBase*
- ByPassAttributeBehaviorHolder (which does not extend anything. it
would extend BehaviorHolder, if it was existed)
public interface ByPassAttributeBehaviorHolder
And implementing component side (please note that I am using MyFaces builder
plugin):
- AbstractByPassTestComponent
@JSFComponent(name = hx:bypassTest,
clazz = tr.com.aliok.html5.bypassbehavior.BypassTestComponent,
tagClass = tr.com.aliok.html5.component.ByPassTestTag)
public abstract class AbstractByPassTestComponent extends UIComponentBase
implements *ByPassAttributeBehaviorHolder*
{...
- ByPassTestRenderer
@JSFRenderer(
renderKitId = HTML_BASIC,
family = tr.com.aliok.html5.ByPassTest,
type = tr.com.aliok.html5.ByPassTest)
public class ByPassTestRenderer extends Renderer
{...
Registration in ...taglib.xml:
tag
tag-namebyPassAttributeBehavior/tag-name
behavior
behavior-idorg.apache.myfaces.html5.ByPassAttributeBehavior/behavior-id
/behavior
/tag
At last, my usage:
hx:bypassTest ...
hx:byPassAttributeBehavior .../
/hx:bypassTest
In this case, at
org.apache.myfaces.view.facelets.tag.jsf.BehaviorTagHandlerDelegate#apply,
an exception is thrown if the parent is not a ClientBehaviorHolder or a
composite component.
...
I think I can solve this problem by writing a tag handler, but why not
supporting this feature without a tag handler just like ClientBehaviors?
We don't have to write tag handlers for ClientBehaviors, but this is not
the case for Behaviors. Seems like the problem is: there is no interface
like BehaviorHolder. Thus the delegate BehaviorTagHandlerDelegate cannot
determine whether the parent is Behavior 'attachable', so it cannot attach
Behaviors to parent.
However, I couldn't understand why there is no interface like BehaviorHolder
and why we need to write a tag handler for a Behavior that doesn't extend
ClientBehavior? If something similar is discussed before, what was the
purpose of this decision?
I see that, we have addClientBehavior method in ClientBehaviorHolder
class. Behaviors are here to get attached, right? So, why this attaching
logic only pushed for 'ClientBehavior's?
Regards,
Ali
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
[GSOC-HTML5] ClientBehavior and ClientBehaviorHolder's attributes
Hi, I am trying to write some prototypes about DnD support. I want to use ClientBehaviors for this issue. I wonder if a code like xx:somePanel ... fx:dragSupportClientBehavior .../ !-- This is A ClientBehavior -- /xx:somePanel can produce div *draggable=true* ondragstart=return dragStart(event) ondragend=return dragEnd(event) /div What I need is, having a ClientBehavior setting an HTML5 element's draggable attribute set to true. Thanks to ClientBehaviors, I can easily set 'ondragstart' and 'ondragend' (in the FaceletHandler of my fx:dragSupportClientBehavior using clientBehaviorHolder.addClientBehavior(dragstart, clientBehavior);) However, producing draggable=true is not that straightforward. On xx:somePanel, I need to check if there is a fx:dragSupportClientBehavior child. At the components that I cannot modify, things got worse. I can never set draggable=true on them: h:inputText fx:dragSupportClientBehavior .../ /h:inputText And, I don't want to use something like: xx:somePanel draggable=true ... fx:dragSupportClientBehavior .../ /xx:somePanel since the information about the component being draggable is written twice. Anyway, is this possible without parent component checking children? It would be nice if we have a chance allowing ClientBehaviors to set some allowed logical and plain attributes just like the events. Any discussions about something like that on jsr314-open or elsewhere? Greetings, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [GSOC-HTML5] ClientBehavior and ClientBehaviorHolder's attributes
At the components that I cannot modify, things got worse. I can never set draggable=true on them: h:inputText fx:dragSupportClientBehavior .../ /h:inputText Ignore these 2 sentences, since I can't set 'ondragstart' and 'ondragend' on h:inputText using a ClientBehavior anyway :) On Sat, May 15, 2010 at 3:02 AM, Ali Ok al...@aliok.com.tr wrote: At the components that I cannot modify, things got worse. I can never set draggable=true on them: h:inputText fx:dragSupportClientBehavior .../ /h:inputText -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[jira] Created: (MYFACES-2705) ClassCastException in HtmlAjaxBehaviorRenderer
ClassCastException in HtmlAjaxBehaviorRenderer -- Key: MYFACES-2705 URL: https://issues.apache.org/jira/browse/MYFACES-2705 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0 Reporter: Ali Ok Priority: Minor ClassCastException in HtmlAjaxBehaviorRenderer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2705) ClassCastException in HtmlAjaxBehaviorRenderer
[ https://issues.apache.org/jira/browse/MYFACES-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali Ok updated MYFACES-2705: Status: Patch Available (was: Open) ClassCastException in HtmlAjaxBehaviorRenderer -- Key: MYFACES-2705 URL: https://issues.apache.org/jira/browse/MYFACES-2705 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0 Reporter: Ali Ok Priority: Minor Attachments: 2705.patch ClassCastException in HtmlAjaxBehaviorRenderer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSOC] New Form Elements
Hi, Thanks for the replies. But also you might get it easier (second option), maybe you wont even need a second lifecycle if you can tackle the problem via JSF2 system events on the controls themselves. Sounds good :) I would recommend also to raise a spec issue there regarding this. I will do it after some research. Thanks, Ali On Thu, May 6, 2010 at 6:43 PM, Mike Kienenberger mkien...@gmail.comwrote: Sounds a lot like the tomahawk sandbox subform and tomahawk UICommand components. You can specify an actionFor attribute on the UICommand components to point at a specific subform. I wonder if some of the design from subform can be reused. On Thu, May 6, 2010 at 10:39 AM, Werner Punz werner.p...@gmail.com wrote: Yes they will definitely need that attribute especially if they are outside of a form. Also the components have to throw an error if the attribute is not set and if they are not hosted inside of a form. Werner Am 06.05.10 16:25, schrieb Kito Mann: On Thu, May 6, 2010 at 4:19 AM, Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com wrote: 2 Possibilities: First, via custom lifecycle, extend the standard elements in a way that they refer to a form element and a first step collect those elements and a second step at, form processing, processes those external elements within the bounds of a form. This applies to the apply request values and validation phases, or probably. Second possibility: But also you might get it easier (second option), maybe you wont even need a second lifecycle if you can tackle the problem via JSF2 system events on the controls themselves. (you can set direct event listeners for various phases on the controls so that they will be processed), this would be even faster since the event handling mechanisms would do the bookkeeping for you which you in the other case would have to do yourself. Using component system events should work fine -- it's how h:outputScript and h:outputStylesheet can retarget themselves to the h:head component. I think the components may need a new forForm attribute, though, for cases when there's more than one form on the page. This is probably the biggest problem with JSF and HTML5 (I did not know this was possible, since I only follow the html 5 development via blogs and articles), I would recommend also to raise a spec issue there regarding this, so that we might, special handling for the official spec so that no impl has to cook its own mechnanism in the long run. https://javaserverfaces-spec-public.dev.java.net/servlets/ProjectIssues Werner Am 05.05.10 20:01, schrieb Ali Ok: Hi all, I've been working on my GSOC project (prototyping currently). I want to ask you something. With HTML5, form elements does not have to be children of a form. Of course, that is the preferred way, but you can set the form attribute of the input and that input will be posted when the owner form is submitted.[0] This also applies to submit buttons, in a similar way. You can define form attribute of the submit button, and it will submit the defined form -not necessarily its parent- when it is clicked.[1] So, I wonder if this can be applied in JSF side. AFAIK currently, a commandButton needs to be under a h:form. This is also about serverside component tree, and maybe state saving. I couldn't set up much in my head. What do you think? How can we use this new features? How to model them? Thanks, Ali [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[GSOC] New Form Elements
Hi all, I've been working on my GSOC project (prototyping currently). I want to ask you something. With HTML5, form elements does not have to be children of a form. Of course, that is the preferred way, but you can set the form attribute of the input and that input will be posted when the owner form is submitted.[0] This also applies to submit buttons, in a similar way. You can define form attribute of the submit button, and it will submit the defined form -not necessarily its parent- when it is clicked.[1] So, I wonder if this can be applied in JSF side. AFAIK currently, a commandButton needs to be under a h:form. This is also about serverside component tree, and maybe state saving. I couldn't set up much in my head. What do you think? How can we use this new features? How to model them? Thanks, Ali [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-statehttp://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
