You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2005/10/06 04:21:23 UTC
New date parser in javascript
Hi *,
I have added the first draft of a javascript date parser - it would be
great if you could check it out, add functionality as needed (should
be pretty straightforward) and (of course) use it!
regards,
Martin
Re: New date parser in javascript
Posted by Martin Marinschek <ma...@gmail.com>.
Very good!
I was hoping that if I plant a seed, a tree starts to grow ;)
need to check out and test the new functionality right away...
Great!
regards,
Martin
On 10/7/05, Arvid Hülsebus <ar...@atanion.com> wrote:
> Looks like I'm ending up spending as much time on date parsing as Martin...
>
> Parsing of MMM and MMMM starts to work now, too. Additionally I looked
> into parsing and formatting of yy vs. yyyy.
>
> Regards,
> Arvid
>
>
> import org.mozilla.javascript.JavaScriptException;
>
> import java.text.SimpleDateFormat;
> import java.text.DecimalFormat;
> import java.text.ParseException;
> import java.util.Date;
> import java.util.Locale;
> import java.util.Calendar;
> import java.io.IOException;
>
> public class DateTest extends JavaScriptTestCase {
>
> private static final int[] YEAR_MONTH_DAY
> = {Calendar.YEAR, Calendar.MONTH, Calendar.DAY_OF_MONTH};
>
> protected void setUp() throws Exception {
> super.setUp();
> // loadScriptFile("debug.js");
> loadScriptFile("prototype-basics.js");
> loadScriptFile("date.js");
> }
>
> public void testNumberOnlyDateFormats() throws IOException, JavaScriptException {
> Date date = new Date();
>
> checkFormat("yyyyMMdd", date, YEAR_MONTH_DAY);
> checkFormat("ddMMyyyy", date, YEAR_MONTH_DAY);
> checkFormat("dd/MM/yyyy", date, YEAR_MONTH_DAY);
> checkFormat("dd/MM/yyy", date, YEAR_MONTH_DAY);
> checkFormat("dd/MM/yy", date, YEAR_MONTH_DAY);
> checkFormat("EddMMyyyy", date, YEAR_MONTH_DAY);
> }
>
> public void testEnglishMonths() throws IOException {
> for (int month = 0; month < 12; ++month) {
> Calendar calendar = Calendar.getInstance(Locale.ENGLISH);
> calendar.set(Calendar.MONTH, month);
> Date date = calendar.getTime();
>
> StringBuffer format = new StringBuffer("M");
> for (int i = 0; i < 4; ++i) {
> format.append('M');
> checkFormat(format.toString(), date, new int[] {Calendar.MONTH});
> }
> }
> }
>
> public void testTwoDigitYears() throws IOException, ParseException {
> DecimalFormat decimalFormat = new DecimalFormat("00");
> SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yy", Locale.ENGLISH);
> Calendar calendar = Calendar.getInstance(Locale.ENGLISH);
> for (int year = 0; year < 100; ++year) {
> String yearString = decimalFormat.format(year);
> calendar.setTime(simpleDateFormat.parse(yearString));
> assertEquals(calendar.get(Calendar.YEAR), evalParseDate(yearString, "yy").get(Calendar.YEAR));
> }
> }
>
> public void testEnglishWeekDays() throws IOException {
> for (int day = 1; day <= 7; ++day) {
> Calendar calendar = Calendar.getInstance();
> calendar.set(Calendar.DAY_OF_WEEK, day);
> Date date = calendar.getTime();
>
> StringBuffer format = new StringBuffer();
> for (int i = 0; i < 4; ++i) {
> format.append('E');
> checkFormat(format.toString(), date, new int[0]); // XXX new int[] {Calendar.DAY_OF_WEEK}
> }
> }
> }
>
> private Object evalFormatDate(Date date, String format) {
> return eval("new SimpleDateFormat(\"" + format + "\")"
> + ".format(new Date(" + date.getTime() + "))");
> }
>
> private Calendar evalParseDate(String input, String format) {
> long time = evalLong("new SimpleDateFormat(\"" + format + "\")"
> + ".parse(\"" + input + "\").getTime()");
> Calendar calendar = Calendar.getInstance(Locale.ENGLISH);
> calendar.setTime(new Date(time));
> return calendar;
> }
>
> private void checkFormat(String format, Date date, int[] fields) {
> SimpleDateFormat simpleDateFormat = new SimpleDateFormat(format, Locale.ENGLISH);
> assertEquals(simpleDateFormat.format(date), evalFormatDate(date, format));
> Calendar calendar1 = Calendar.getInstance(Locale.ENGLISH);
> calendar1.setTime(date);
> Calendar calendar2 = evalParseDate(simpleDateFormat.format(date), format.toString());
> for (int i = 0; i < fields.length; i++) {
> int field = fields[i];
> checkField(calendar1, calendar2, field);
> }
> }
>
> private void checkField(Calendar calendar1, Calendar calendar2, int field) {
> assertEquals(calendar1.get(field), calendar2.get(field));
> }
>
> }
>
>
> import junit.framework.TestCase;
> import org.mozilla.javascript.Context;
> import org.mozilla.javascript.Scriptable;
> import org.mozilla.javascript.JavaScriptException;
>
> import java.io.IOException;
> import java.io.FileReader;
> import java.util.Date;
>
> public class JavaScriptTestCase extends TestCase {
>
> protected Context cx;
> protected Scriptable scope;
>
> protected void setUp() throws Exception {
> super.setUp();
> cx = Context.enter();
> scope = cx.initStandardObjects(null);
> }
>
> protected void tearDown() throws Exception {
> Context.exit();
> }
>
> protected Object eval(String script) throws JavaScriptException {
> return cx.evaluateString(scope, script, "test", 1, null);
> }
>
> protected int evalInt(String script) throws JavaScriptException {
> Object o = eval(script);
> if (o instanceof Number) {
> return ((Number) o).intValue();
> }
> throw new JavaScriptException(null, "invalid return type "
> + o.getClass().getName() + " with value " + o, 0);
> }
>
> protected long evalLong(String script) throws JavaScriptException {
> Object o = eval(script);
> if (o instanceof Number) {
> return ((Number) o).longValue();
> }
> throw new JavaScriptException(null, "invalid return type "
> + o.getClass().getName() + " with value " + o, 0);
> }
>
> protected boolean evalBoolean(String script) throws JavaScriptException {
> Object o = eval(script);
> if (o instanceof Boolean) {
> return ((Boolean) o).booleanValue();
> }
> throw new JavaScriptException(null, "invalid return type "
> + o.getClass().getName() + " with value " + o, 0);
> }
>
> // XXX directory handling
> protected void loadScriptFile(String jsFile)
> throws IOException, JavaScriptException {
> cx.evaluateReader(scope, new FileReader(jsFile), jsFile, 0, null);
> }
> }
>
>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: New date parser in javascript
Posted by Arvid Hülsebus <ar...@atanion.com>.
Looks like I'm ending up spending as much time on date parsing as Martin...
Parsing of MMM and MMMM starts to work now, too. Additionally I looked
into parsing and formatting of yy vs. yyyy.
Regards,
Arvid
Re: New date parser in javascript
Posted by Arvid Hülsebus <ar...@atanion.com>.
I started to look into the formatting of MMM, MMMM, EEE, and EEEE...
just a start. Hope it helps.
Regards,
Arvid
Re: New date parser in javascript
Posted by Arvid Hülsebus <ar...@atanion.com>.
Dang... sent the wrong unit test. This was were I started to test the
script, which we are currently using in Tobago. My test for
https://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/src/java/org/apache/myfaces/custom/calendar/resource/date.js
looks something like the attached file.
Regards,
Arvid
Re: New date parser in javascript
Posted by Arvid Hülsebus <ar...@atanion.com>.
We need to replace some JavaScript code in Tobago, which has basically
the same functionality like the new date.js stuff. I started to work on
this, too. Perhaps we should join forces. But I definitely don't have as
much time as Martin -- working on this the whole night...
I pulled together some ends from a nearly abandoned web test tool of
ours and started to write a JavaScriptTestCase. Now seeing that Martin's
date parsing and formatting code is far more advanced than my stuff I
came up with yesterday, I thought my unit testing stuff could be somehow
useful for you, too. It just some very basic code using Mozilla's Rhino.
But this way it's easier to test the JavaScript code from your Java IDE
and at least for Tobago I need to be pretty close to the Java
implementation of SimpleDateFormat. This way the two implementations can
be compared pretty easily.
I spotted some problems regarding formats including "MMM" and "MMMM".
But I didn't have the time to look into the JavaScript implementation up
to now. I hope I can do this, when I got home and something to eat.
I will need a more sophisticated approach for localization, too ;-) I
will provide some suggestions to this later...
Regards,
Arvid
Martin Marinschek wrote:
>Hi *,
>
>I have added the first draft of a javascript date parser - it would be
>great if you could check it out, add functionality as needed (should
>be pretty straightforward) and (of course) use it!
>
>regards,
>
>Martin
>
>
Re: JavaScript in MyFaces (was Re: New date parser in javascript)
Posted by Martin Marinschek <ma...@gmail.com>.
No,
Rico.Toggler does not belong to Rico, and I (basing it on the Rico
library) made the mistake of not declaring a new namespace for it so
far.
(actually I was also considering donating it back to Rico at some
point in time, let's see how this works out).
I will correct this ASAP.
regards,
Martin
On 10/8/05, Martin Cooper <ma...@apache.org> wrote:
>
>
> On Sat, 8 Oct 2005, Werner Punz wrote:
>
> > Martin Cooper wrote:
> >> Let me give a couple of examples of problems MyFaces is facing right now.
> >>
> >> 1) Prototype messes with fundamental JavaScript types. One of the first
> >> things is does is add a new function to Object! Things like this can
> >> seriously mess up other JavaScript code. As just one example, it renders
> >> the 'for ... in ...' construct effectively useless, because you will
> >> *always* get back more entries than you put in, since Prototype is
> >> adding some for you. And it's not only to Object, either, as even a
> >
> >> quick glance at prototype.js will show.
> >>
> > Issue is fixed soon, apparently the authors are aware of this problem:
> >
> > http://wrath.rubyonrails.org/pipermail/rails-spinoffs/2005-September/000827.html
>
> Great! I'll take a look at that. Hopefully they've fixed all of the cases,
> and not just Object. ;-)
>
> > This is pretty much the only issue the basic proto lib has with conflicts
> > into other subsystems (except for maybe the namespace stuff), to my knowledge if
> > someone knows others please point me towards it.
> >
> >> 2) Namespacing is a big problem already. Prototype, Rico and all the
> >> other JavaScript code I've looked at in the MyFaces repo create numerous
> >> artifacts in the global namespace, often with names that are very likely
> >> to be chosen by other people writing JavaScript (although Rico is much
> >> better in this respect). Examples: Prototype creates Form and Field,
> >> Rico and Scriptaculous create Effect. These will either clobber, or be
> >> clobbered by, other artifacts from other sources used in the same page.
> >>
> > I agree with this problem, it can be easily fixed, either by us
> > or by others, fact is,
> > the code does a lot which we have to duplicate and there is definitely
> > a huge momentum behind that codebase, that things like OpenRico and Scriptaculous
> > exist is proof enough, so it would be sad to lock it out
> > especially for a problem as easily fixable as that one
>
> I didn't mean to imply that you shouldn't use useful JavaScript libs. Just
> that some of these issues need to be discussed and resolved. It would be
> good to encourage the authors of those other libs to think about it more
> as well, so that you don't have to solve their problems. ;-)
>
> >> 3) The biggest problem area with the above is portlets. You have *no*
> >> control over what other JavaScript is going to be included on a page.
> >> This makes the likelihood very high that #1 and / or #2 is going to
> >> screw up all of the other portlets on the page, even if it doesn't screw
> >> up the portlet created by MyFaces. Either that, or the MyFaces portlet
> >> will be screwed up by the other JavaScript. Either way, that will not
> >> make you many friends. ;-)
> >>
> > Actually I do not see portlets really as the problem, if we have a single
> > include of the lib and the namespace issue is fixed.
> >
> > The library itself is fully OO which means you work with single objects
> > per portlet,
> >
> > for instance portlet a uses a fade
> > portlet b uses a simple puff
> >
> > portlet a:
> >
> > onload="javascript:new Effect.Fade(this);"
> >
> > portlet b:
> > onClick="javascript:new Effect.Puff(this);"
> >
> > Two objects are generated with no conflicts at all between those portlets.
> >
> > If an author however thinks he has to to some special stuff in his/her portlets
> > within the same namespaces... well javascript allows that but
> > but in the end you might end up in a mess.
>
> That's exactly my point. Portlets built with MyFaces are going to coexist
> on pages with portlets not built with MyFaces. If one of those portlets
> defines an Effect class, for example, something's going to break.
>
> Obviously you can't fix everyone else's problems. ;-) However, if I use
> Dojo, for example, I know that all of the Dojo code exists in the 'dojo'
> namespace, and I can create all of my code in the 'martinc' namespace,
> thus truly minimising the risk of clobbering or being clobbered. That's
> what I'm encouraging you to think about.
>
> > My general opinion is, the proto stuff is pretty safe portletwise,
> > other javascripts (believe me the proto stuff is some of the best you can find,
> > I have seen much worse) are much less save than proto regarding portlets.
> > Mainly the most portlet problematic javascripts are those who do not use
> > javascript classes at all but go for a pure functional approach,
> > often this stuff does not the proper way to encapsule the data
> > to handle those issues but
> > are coded for only one object at a time, which works normally then
> > on a single page but breaks heavily on a portlet environment.
> >
> > Once the namespace issue is fixed, this is also fixed to a at least
> > for me satisfying degree.
>
> Along with the already-fixed extension problem, I agree.
>
> >> 4) Another thing that could be a problem at some point is that I see at
> >> least some code that is creating MyFaces classes inside of Rico's
> >> namespace (e.g. Rico.Toggler). Since you don't control that namespace,
> >> you could easily be hosed when a new version of Rico comes along that
> >> defines something with the same name that you are using. Here I would
> >> suggest simply defining your own namespace (e.g. MyFaces).
> >>
> > Martin has to comment on that, since he has the supervision over the toggler,
> > I have not checked it out yet except for the demo.
>
> Actually, on looking more closely, it seems that Rico.Toggler is probably
> part of Rico, but for some reason ships in its own file.
>
> --
> Martin Cooper
>
>
> >>
> >> There's also a lot of interesting and very sophisticated stuff going on
> >> that doesn't use either Rails or Prototype, including live commercial
> >> sites.
> >>
> >> I would recommend taking a look at Dojo. It has excellent "Ajax" support
> >> and an awesome event system. It is also fully namespaced. See:
> >>
> >> http://dojotoolkit.org/
> >> http://dojotoolkit.org/docs/intro_to_dojo_io.html
> >> http://dojotoolkit.org/docs/dojo_event_system.html
> >>
> > I will check it out, having more than a handful of tools in our hands is always good.
> >
> > Thanks for pointing me towards it I have not been aware of it.
> >
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: JavaScript in MyFaces (was Re: New date parser in javascript)
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 8 Oct 2005, Werner Punz wrote:
> Martin Cooper wrote:
>> Let me give a couple of examples of problems MyFaces is facing right now.
>>
>> 1) Prototype messes with fundamental JavaScript types. One of the first
>> things is does is add a new function to Object! Things like this can
>> seriously mess up other JavaScript code. As just one example, it renders
>> the 'for ... in ...' construct effectively useless, because you will
>> *always* get back more entries than you put in, since Prototype is
>> adding some for you. And it's not only to Object, either, as even a
>
>> quick glance at prototype.js will show.
>>
> Issue is fixed soon, apparently the authors are aware of this problem:
>
> http://wrath.rubyonrails.org/pipermail/rails-spinoffs/2005-September/000827.html
Great! I'll take a look at that. Hopefully they've fixed all of the cases,
and not just Object. ;-)
> This is pretty much the only issue the basic proto lib has with conflicts
> into other subsystems (except for maybe the namespace stuff), to my knowledge if
> someone knows others please point me towards it.
>
>> 2) Namespacing is a big problem already. Prototype, Rico and all the
>> other JavaScript code I've looked at in the MyFaces repo create numerous
>> artifacts in the global namespace, often with names that are very likely
>> to be chosen by other people writing JavaScript (although Rico is much
>> better in this respect). Examples: Prototype creates Form and Field,
>> Rico and Scriptaculous create Effect. These will either clobber, or be
>> clobbered by, other artifacts from other sources used in the same page.
>>
> I agree with this problem, it can be easily fixed, either by us
> or by others, fact is,
> the code does a lot which we have to duplicate and there is definitely
> a huge momentum behind that codebase, that things like OpenRico and Scriptaculous
> exist is proof enough, so it would be sad to lock it out
> especially for a problem as easily fixable as that one
I didn't mean to imply that you shouldn't use useful JavaScript libs. Just
that some of these issues need to be discussed and resolved. It would be
good to encourage the authors of those other libs to think about it more
as well, so that you don't have to solve their problems. ;-)
>> 3) The biggest problem area with the above is portlets. You have *no*
>> control over what other JavaScript is going to be included on a page.
>> This makes the likelihood very high that #1 and / or #2 is going to
>> screw up all of the other portlets on the page, even if it doesn't screw
>> up the portlet created by MyFaces. Either that, or the MyFaces portlet
>> will be screwed up by the other JavaScript. Either way, that will not
>> make you many friends. ;-)
>>
> Actually I do not see portlets really as the problem, if we have a single
> include of the lib and the namespace issue is fixed.
>
> The library itself is fully OO which means you work with single objects
> per portlet,
>
> for instance portlet a uses a fade
> portlet b uses a simple puff
>
> portlet a:
>
> onload="javascript:new Effect.Fade(this);"
>
> portlet b:
> onClick="javascript:new Effect.Puff(this);"
>
> Two objects are generated with no conflicts at all between those portlets.
>
> If an author however thinks he has to to some special stuff in his/her portlets
> within the same namespaces... well javascript allows that but
> but in the end you might end up in a mess.
That's exactly my point. Portlets built with MyFaces are going to coexist
on pages with portlets not built with MyFaces. If one of those portlets
defines an Effect class, for example, something's going to break.
Obviously you can't fix everyone else's problems. ;-) However, if I use
Dojo, for example, I know that all of the Dojo code exists in the 'dojo'
namespace, and I can create all of my code in the 'martinc' namespace,
thus truly minimising the risk of clobbering or being clobbered. That's
what I'm encouraging you to think about.
> My general opinion is, the proto stuff is pretty safe portletwise,
> other javascripts (believe me the proto stuff is some of the best you can find,
> I have seen much worse) are much less save than proto regarding portlets.
> Mainly the most portlet problematic javascripts are those who do not use
> javascript classes at all but go for a pure functional approach,
> often this stuff does not the proper way to encapsule the data
> to handle those issues but
> are coded for only one object at a time, which works normally then
> on a single page but breaks heavily on a portlet environment.
>
> Once the namespace issue is fixed, this is also fixed to a at least
> for me satisfying degree.
Along with the already-fixed extension problem, I agree.
>> 4) Another thing that could be a problem at some point is that I see at
>> least some code that is creating MyFaces classes inside of Rico's
>> namespace (e.g. Rico.Toggler). Since you don't control that namespace,
>> you could easily be hosed when a new version of Rico comes along that
>> defines something with the same name that you are using. Here I would
>> suggest simply defining your own namespace (e.g. MyFaces).
>>
> Martin has to comment on that, since he has the supervision over the toggler,
> I have not checked it out yet except for the demo.
Actually, on looking more closely, it seems that Rico.Toggler is probably
part of Rico, but for some reason ships in its own file.
--
Martin Cooper
>>
>> There's also a lot of interesting and very sophisticated stuff going on
>> that doesn't use either Rails or Prototype, including live commercial
>> sites.
>>
>> I would recommend taking a look at Dojo. It has excellent "Ajax" support
>> and an awesome event system. It is also fully namespaced. See:
>>
>> http://dojotoolkit.org/
>> http://dojotoolkit.org/docs/intro_to_dojo_io.html
>> http://dojotoolkit.org/docs/dojo_event_system.html
>>
> I will check it out, having more than a handful of tools in our hands is always good.
>
> Thanks for pointing me towards it I have not been aware of it.
>
>
Re: JavaScript in MyFaces (was Re: New date parser in javascript)
Posted by Werner Punz <we...@gmx.at>.
Martin Cooper wrote:
> Let me give a couple of examples of problems MyFaces is facing right now.
>
> 1) Prototype messes with fundamental JavaScript types. One of the first
> things is does is add a new function to Object! Things like this can
> seriously mess up other JavaScript code. As just one example, it renders
> the 'for ... in ...' construct effectively useless, because you will
> *always* get back more entries than you put in, since Prototype is
> adding some for you. And it's not only to Object, either, as even a
> quick glance at prototype.js will show.
>
Issue is fixed soon, apparently the authors are aware of this problem:
http://wrath.rubyonrails.org/pipermail/rails-spinoffs/2005-September/000827.html
This is pretty much the only issue the basic proto lib has with conflicts
into other subsystems (except for maybe the namespace stuff), to my knowledge if
someone knows others please point me towards it.
> 2) Namespacing is a big problem already. Prototype, Rico and all the
> other JavaScript code I've looked at in the MyFaces repo create numerous
> artifacts in the global namespace, often with names that are very likely
> to be chosen by other people writing JavaScript (although Rico is much
> better in this respect). Examples: Prototype creates Form and Field,
> Rico and Scriptaculous create Effect. These will either clobber, or be
> clobbered by, other artifacts from other sources used in the same page.
>
I agree with this problem, it can be easily fixed, either by us
or by others, fact is,
the code does a lot which we have to duplicate and there is definitely
a huge momentum behind that codebase, that things like OpenRico and Scriptaculous
exist is proof enough, so it would be sad to lock it out
especially for a problem as easily fixable as that one
> 3) The biggest problem area with the above is portlets. You have *no*
> control over what other JavaScript is going to be included on a page.
> This makes the likelihood very high that #1 and / or #2 is going to
> screw up all of the other portlets on the page, even if it doesn't screw
> up the portlet created by MyFaces. Either that, or the MyFaces portlet
> will be screwed up by the other JavaScript. Either way, that will not
> make you many friends. ;-)
>
Actually I do not see portlets really as the problem, if we have a single
include of the lib and the namespace issue is fixed.
The library itself is fully OO which means you work with single objects
per portlet,
for instance portlet a uses a fade
portlet b uses a simple puff
portlet a:
onload="javascript:new Effect.Fade(this);"
portlet b:
onClick="javascript:new Effect.Puff(this);"
Two objects are generated with no conflicts at all between those portlets.
If an author however thinks he has to to some special stuff in his/her portlets
within the same namespaces... well javascript allows that but
but in the end you might end up in a mess.
My general opinion is, the proto stuff is pretty safe portletwise,
other javascripts (believe me the proto stuff is some of the best you can find,
I have seen much worse) are much less save than proto regarding portlets.
Mainly the most portlet problematic javascripts are those who do not use
javascript classes at all but go for a pure functional approach,
often this stuff does not the proper way to encapsule the data
to handle those issues but
are coded for only one object at a time, which works normally then
on a single page but breaks heavily on a portlet environment.
Once the namespace issue is fixed, this is also fixed to a at least
for me satisfying degree.
> 4) Another thing that could be a problem at some point is that I see at
> least some code that is creating MyFaces classes inside of Rico's
> namespace (e.g. Rico.Toggler). Since you don't control that namespace,
> you could easily be hosed when a new version of Rico comes along that
> defines something with the same name that you are using. Here I would
> suggest simply defining your own namespace (e.g. MyFaces).
>
Martin has to comment on that, since he has the supervision over the toggler,
I have not checked it out yet except for the demo.
>
>
> There's also a lot of interesting and very sophisticated stuff going on
> that doesn't use either Rails or Prototype, including live commercial
> sites.
>
> I would recommend taking a look at Dojo. It has excellent "Ajax" support
> and an awesome event system. It is also fully namespaced. See:
>
> http://dojotoolkit.org/
> http://dojotoolkit.org/docs/intro_to_dojo_io.html
> http://dojotoolkit.org/docs/dojo_event_system.html
>
I will check it out, having more than a handful of tools in our hands is always good.
Thanks for pointing me towards it I have not been aware of it.
Re: JavaScript in MyFaces (was Re: New date parser in javascript)
Posted by Martin Cooper <ma...@apache.org>.
On Fri, 7 Oct 2005, Werner Punz wrote:
> Martin Cooper wrote:
>> Can I suggest a high-level discussion of how you're going to structure
>> all of the JavaScript code in MyFaces? I'm concerned that you'll end up
>> with a fragmented JavaScript code base, with each widget using its own
>> style and way of doing things, which would be, um, less than optimal.
>>
>> I'm also very concerned right now that, unless I'm mistaken, all of the
>> code seems to be going into the global JavaScript namespace. This is OK,
>> I guess, if you're building an application, but it's definitely not OK
>> for a toolkit, since you're quickly going to end up with conflicts as
>> people use your toolkit to build applications. (Unfortunately, it seems
>> that the Prototype toolkit itself has this problem.)
>>
>> My 2 cents...
>>
> Very good idea, I am interested in that too, because the more
> we move towards ajax the more javascript dependencies we get...
> Also we need some consensous which javascript libs for now we use.
>
> Currently Martin and I settled for the proto lib (he for the accordeon
> panel and the ajax stuff, I for the effects tag) in the sandbox depending
> on it, DWR is out of the scope for both of us afair because it
> introduces yet another set of xml config files.
> (Cannot speak for Martin directly, of course, but I remember such a
> discussion I had with him)
> Martin in the sandbox already has moved the proto lib stuff into its own
> and slowly is introducing stuff which is based upon it (the accordeon
> panel for instance), we should follow something like that approach.
Let me give a couple of examples of problems MyFaces is facing right now.
1) Prototype messes with fundamental JavaScript types. One of the first
things is does is add a new function to Object! Things like this can
seriously mess up other JavaScript code. As just one example, it renders
the 'for ... in ...' construct effectively useless, because you will
*always* get back more entries than you put in, since Prototype is adding
some for you. And it's not only to Object, either, as even a quick glance
at prototype.js will show.
2) Namespacing is a big problem already. Prototype, Rico and all the other
JavaScript code I've looked at in the MyFaces repo create numerous
artifacts in the global namespace, often with names that are very likely
to be chosen by other people writing JavaScript (although Rico is much
better in this respect). Examples: Prototype creates Form and Field, Rico
and Scriptaculous create Effect. These will either clobber, or be
clobbered by, other artifacts from other sources used in the same page.
3) The biggest problem area with the above is portlets. You have *no*
control over what other JavaScript is going to be included on a page. This
makes the likelihood very high that #1 and / or #2 is going to screw up
all of the other portlets on the page, even if it doesn't screw up the
portlet created by MyFaces. Either that, or the MyFaces portlet will be
screwed up by the other JavaScript. Either way, that will not make you
many friends. ;-)
4) Another thing that could be a problem at some point is that I see at
least some code that is creating MyFaces classes inside of Rico's
namespace (e.g. Rico.Toggler). Since you don't control that namespace, you
could easily be hosed when a new version of Rico comes along that defines
something with the same name that you are using. Here I would suggest
simply defining your own namespace (e.g. MyFaces).
> proto loader
> ... scriptaculo.us separate loader but having a dep into proto and
> shared over components
> ... other libraries also shared
> ... local component stuff still local but it should be recommended to
> dock to one of the existing libs to keep the code as tight as possible
> (prototype based code has the tendency to be very tight due to the oo
> structures prototype introduces to javascript)
>
> As for the introduction of DWR... I would stay away from it until they
> have resolved the xml config file issues
> There isnt too much in DWR which cannot be solved in proto or one
> of the libs.
>
> To my knowledge most of the interesting stuff on the javascript side
> itself currently is driven by Rails and proto based stuff, so it would
> be wise to follow that approach for the time being.
There's also a lot of interesting and very sophisticated stuff going on
that doesn't use either Rails or Prototype, including live commercial
sites.
I would recommend taking a look at Dojo. It has excellent "Ajax" support
and an awesome event system. It is also fully namespaced. See:
http://dojotoolkit.org/
http://dojotoolkit.org/docs/intro_to_dojo_io.html
http://dojotoolkit.org/docs/dojo_event_system.html
--
Martin Cooper
Re: JavaScript in MyFaces (was Re: New date parser in javascript)
Posted by Werner Punz <we...@gmx.at>.
I followed Martins way in this case
by using the resource loader he defined for the lib
if (javascriptLocation == null)
{
AddResource.addJavaScriptToHeader(PrototypeResourceLoader.class,
"prototype.js", context);
AddResource.addJavaScriptToHeader(PrototypeResourceLoader.class,
"effects.js", context);
AddResource.addJavaScriptToHeader(EffectRenderer.class, "fat.js",
context);
}
the code is basically how Martin does it, and I am doing it
the scripts are located under the respective resource dirs
of the loader components.
By moving the proto lib into a separate resource loader
entity Martin was able to avoid double includes
of the prototype libs.
what happens on the html side if things is that once this is
done an include to the page is added at the appropriate place.
The namespace problem is not a real problem here, because
once the scripts are on top of the prototpe lib you have
normally no function definitions just once included reusable
class definitions with inheritance.
The trick is that you have to use the scripts as I understand it
once they are shared into their own resource loader components
to avoid double includes and namespace problems.
Werner
Travis Reeder wrote:
> How are you including the javascript now? In the page or linking to
> prototype.js?
>
> Travis
>
> On 10/7/05, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>> wrote:
>
> Martin Cooper wrote:
> > Can I suggest a high-level discussion of how you're going to structure
> > all of the JavaScript code in MyFaces? I'm concerned that you'll
> end up
> > with a fragmented JavaScript code base, with each widget using its
> own
> > style and way of doing things, which would be, um, less than optimal.
> >
> > I'm also very concerned right now that, unless I'm mistaken, all
> of the
> > code seems to be going into the global JavaScript namespace. This
> is OK,
> > I guess, if you're building an application, but it's definitely not OK
> > for a toolkit, since you're quickly going to end up with conflicts as
> > people use your toolkit to build applications. (Unfortunately, it
> seems
> > that the Prototype toolkit itself has this problem.)
> >
> > My 2 cents...
> >
> Very good idea, I am interested in that too, because the more
> we move towards ajax the more javascript dependencies we get...
> Also we need some consensous which javascript libs for now we use.
>
> Currently Martin and I settled for the proto lib (he for the accordeon
> panel and the ajax stuff, I for the effects tag) in the sandbox
> depending
> on it, DWR is out of the scope for both of us afair because it
> introduces yet another set of xml config files.
> (Cannot speak for Martin directly, of course, but I remember such a
> discussion I had with him)
> Martin in the sandbox already has moved the proto lib stuff into its own
> and slowly is introducing stuff which is based upon it (the accordeon
> panel for instance), we should follow something like that approach.
>
> proto loader
> ... scriptaculo.us <http://scriptaculo.us> separate loader but
> having a dep into proto and
> shared over components
> ... other libraries also shared
> ... local component stuff still local but it should be recommended to
> dock to one of the existing libs to keep the code as tight as possible
> (prototype based code has the tendency to be very tight due to the oo
> structures prototype introduces to javascript)
>
> As for the introduction of DWR... I would stay away from it until they
> have resolved the xml config file issues
> There isnt too much in DWR which cannot be solved in proto or one
> of the libs.
>
> To my knowledge most of the interesting stuff on the javascript side
> itself currently is driven by Rails and proto based stuff, so it would
> be wise to follow that approach for the time being.
>
>
Re: JavaScript in MyFaces (was Re: New date parser in javascript)
Posted by Travis Reeder <tr...@gmail.com>.
How are you including the javascript now? In the page or linking to
prototype.js?
Travis
On 10/7/05, Werner Punz <we...@gmx.at> wrote:
>
> Martin Cooper wrote:
> > Can I suggest a high-level discussion of how you're going to structure
> > all of the JavaScript code in MyFaces? I'm concerned that you'll end up
> > with a fragmented JavaScript code base, with each widget using its own
> > style and way of doing things, which would be, um, less than optimal.
> >
> > I'm also very concerned right now that, unless I'm mistaken, all of the
> > code seems to be going into the global JavaScript namespace. This is OK,
> > I guess, if you're building an application, but it's definitely not OK
> > for a toolkit, since you're quickly going to end up with conflicts as
> > people use your toolkit to build applications. (Unfortunately, it seems
> > that the Prototype toolkit itself has this problem.)
> >
> > My 2 cents...
> >
> Very good idea, I am interested in that too, because the more
> we move towards ajax the more javascript dependencies we get...
> Also we need some consensous which javascript libs for now we use.
>
> Currently Martin and I settled for the proto lib (he for the accordeon
> panel and the ajax stuff, I for the effects tag) in the sandbox depending
> on it, DWR is out of the scope for both of us afair because it
> introduces yet another set of xml config files.
> (Cannot speak for Martin directly, of course, but I remember such a
> discussion I had with him)
> Martin in the sandbox already has moved the proto lib stuff into its own
> and slowly is introducing stuff which is based upon it (the accordeon
> panel for instance), we should follow something like that approach.
>
> proto loader
> ... scriptaculo.us <http://scriptaculo.us> separate loader but having a
> dep into proto and
> shared over components
> ... other libraries also shared
> ... local component stuff still local but it should be recommended to
> dock to one of the existing libs to keep the code as tight as possible
> (prototype based code has the tendency to be very tight due to the oo
> structures prototype introduces to javascript)
>
> As for the introduction of DWR... I would stay away from it until they
> have resolved the xml config file issues
> There isnt too much in DWR which cannot be solved in proto or one
> of the libs.
>
> To my knowledge most of the interesting stuff on the javascript side
> itself currently is driven by Rails and proto based stuff, so it would
> be wise to follow that approach for the time being.
>
>
Re: JavaScript in MyFaces (was Re: New date parser in javascript)
Posted by Werner Punz <we...@gmx.at>.
Martin Cooper wrote:
> Can I suggest a high-level discussion of how you're going to structure
> all of the JavaScript code in MyFaces? I'm concerned that you'll end up
> with a fragmented JavaScript code base, with each widget using its own
> style and way of doing things, which would be, um, less than optimal.
>
> I'm also very concerned right now that, unless I'm mistaken, all of the
> code seems to be going into the global JavaScript namespace. This is OK,
> I guess, if you're building an application, but it's definitely not OK
> for a toolkit, since you're quickly going to end up with conflicts as
> people use your toolkit to build applications. (Unfortunately, it seems
> that the Prototype toolkit itself has this problem.)
>
> My 2 cents...
>
Very good idea, I am interested in that too, because the more
we move towards ajax the more javascript dependencies we get...
Also we need some consensous which javascript libs for now we use.
Currently Martin and I settled for the proto lib (he for the accordeon
panel and the ajax stuff, I for the effects tag) in the sandbox depending
on it, DWR is out of the scope for both of us afair because it
introduces yet another set of xml config files.
(Cannot speak for Martin directly, of course, but I remember such a
discussion I had with him)
Martin in the sandbox already has moved the proto lib stuff into its own
and slowly is introducing stuff which is based upon it (the accordeon
panel for instance), we should follow something like that approach.
proto loader
... scriptaculo.us separate loader but having a dep into proto and
shared over components
... other libraries also shared
... local component stuff still local but it should be recommended to
dock to one of the existing libs to keep the code as tight as possible
(prototype based code has the tendency to be very tight due to the oo
structures prototype introduces to javascript)
As for the introduction of DWR... I would stay away from it until they
have resolved the xml config file issues
There isnt too much in DWR which cannot be solved in proto or one
of the libs.
To my knowledge most of the interesting stuff on the javascript side
itself currently is driven by Rails and proto based stuff, so it would
be wise to follow that approach for the time being.
JavaScript in MyFaces (was Re: New date parser in javascript)
Posted by Martin Cooper <ma...@apache.org>.
Can I suggest a high-level discussion of how you're going to structure all
of the JavaScript code in MyFaces? I'm concerned that you'll end up with a
fragmented JavaScript code base, with each widget using its own style and
way of doing things, which would be, um, less than optimal.
I'm also very concerned right now that, unless I'm mistaken, all of the
code seems to be going into the global JavaScript namespace. This is OK, I
guess, if you're building an application, but it's definitely not OK for a
toolkit, since you're quickly going to end up with conflicts as people use
your toolkit to build applications. (Unfortunately, it seems that the
Prototype toolkit itself has this problem.)
My 2 cents...
--
Martin Cooper
On Thu, 6 Oct 2005, Martin Marinschek wrote:
> Hi *,
>
> I have added the first draft of a javascript date parser - it would be
> great if you could check it out, add functionality as needed (should
> be pretty straightforward) and (of course) use it!
>
> regards,
>
> Martin
>