Prototype library and portlets

[Werner Punz <we...@gmx.at>]

Ok because someone raised this issue, I thought things over and came to 
the conclusion a second time, there is no real issue.

First of all, I am not an expert with the newer portlet libraries, but I 
have had some extensive knowledge with Jetspeed 1 (1.4b3 exactly, which 
once I did a bigger portal with)

I do not see a huge deal with using the library in a portlet 
environment. At least not bigger than with any other javascript.
But please correct me if I am wrong with it.

First of all. What happens in a portlet environment. Several backend 
code related objects are replaced with ones which are then shared over a 
central context.
Portlets themselves have for instance their own contexts managing their 
own environments.
(In jetspeed1 it was just the jetspeed context which every portlet had 
its own and then the global turbine context which itself was derived 
from the velocity context of the underlying turbine framework)

The rest is adjusting the events or special events to portlets (like 
minimizing, maximizing etc...)

On the frontend side, you basically render the subforms into a single 
page by some kind of layouting mechanism (which already means the form 
layout has to be adjusted somewhat to the changed environment)

So how does proto could conflict.
a) ID handling, I do not really see a big problem there, portlets have 
to behave at the frontend like every other html page, thus
the ids with same components over different portlets, have to adjust, if 
not you get bigger problems in other areas than javascript!

b) Conflicting Javascript code. Given the fact that myfaces to my 
knowledge already has code in place which prevents double imports of 
javascript, there is no conflict on code import level.

The rest is abstracted by the class/object structure to a certain degree
all which basically has to be done, is that the javascript code either 
is inlined as event triggers, or that generated objects have to be 
adjusted to the component ids (which is mandatory anyway, due to the 
fact that you can use two different components of the same type on the 
same page)

So I assume proto is way less critical in this area than normal 
javascript code which could run into double declaration problems of 
functions way easier if programmed sloppily.

The rest of the conflicts is inherent in both pure javascript and 
prototyped javascript. (namespace conflicts conflicts due to dyanmic 
structures of the language etc...)

c) Prototyes changing of base classes,
yes this is indeed a problem and a problem the devs are aware, one huge 
issue has been arisen in the past with the addition of additional 
Methods to Object which basically caused in interference with iterations 
over object. This issue has been reported and is being or has been (I do 
not know the status exactly) addressed.
This seems so far being the most critical problem of the proto lib, 
given its high usage percentage (it is the core js lib of rails) and 
that it has been actively developed for a while now, others should have 
arrived by now, but have not and if have been addressed.
(one issue was a browser memory leak, which martin reported and was 
addressed in a short period of time)


I do not see the proto lib as critical problem in a portlet environment, 
but given that my knowledge of those environments is somewhat old, you 
might correct me.
Moving a code from a normal to a portlet environment never is that easy 
you sometimes run into conflicts, but the proto lib seems not like a 
showstopper to me. Not bigger or less big than in a normal page 
environment and not bigger than any javascript code in a portlet based 
system.

I just wanted to drop this food for thought and discussion in here, 
because somebody asked the question, and I think it is a serious 
concern, and that is basically what I can conclude with my knowledge I 
have about this stuff.
(My personal opinions about portlets generally being put aside)

Re: Prototype library and portlets

[Matthias Wessendorf <mw...@gmail.com>]

Werner-

I just played w/ pluto1.0.1 and MyFacesGenericPortlet to look at
ajax-faces-portlet-stuff.
However, I wasn't able to get <s:inputSuggestAjax /> runing :-(
I thought the problem could be the ServletFilter for resource serving,
but as I wrote yet another "ajax input suggest component" w/ using
PhaseListener for serving resource, I also wasn't able to get this
stuff running.

(standalone as *traditional* JSF app, it works (both))

-Matthias

Re: Prototype library and portlets

[Werner Punz <we...@gmx.at>]

Mike Kienenberger wrote:
> I admit I've never looked at prototype, but what about the option of
> fixing the namespace issues and contributing the fixes back to the
> prototype project?
> 
The namespace issue is the smallest one, given the fact
that you can fix it with a handful of global replaces.
(And yes, if it is done it should be done and given back not be
done constantly within myfaces)
And I do not see it as a real problem currently, since there have not
been any real issues in this area for the last year, I am aware of.

The main problem is more the fiddeling around with basic javascript
structures, which then makes the code very compact, but can cause
interference problems (and has, ask the Struts people ;-) )

The main problem is that a proposed switching to DOJO does not make
sense at the current state of DOJO (see my other post I just sent)

DOJOs loading times are, lets put it mildly good for spending a stress
free few dozends of seconds) and DOJOs state is currently under heavy
fluctuation (which is the smaller issue, given the fact that they have a
deprecation mechanism).

So Martins advice probably is the best, lets way what Oracle is putting
onto the table.
Although things like this here are really intriguing:

http://archive.dojotoolkit.org/nightly/demos/widget/Fisheye.html
http://archive.dojotoolkit.org/nightly/demos/widget/Panes.html

Re: Prototype library and portlets

[Mike Kienenberger <mk...@gmail.com>]

I admit I've never looked at prototype, but what about the option of
fixing the namespace issues and contributing the fixes back to the
prototype project?

On 1/3/06, Werner Punz <we...@gmx.at> wrote:
> The namespacing problem can be resolved with code gens which add
> automatically the namespaces,
>
> the javascript type problem is indeed there
> (although it seems to be not that critical, due to the inherent messy
> nature of javascript itself, but I agree
> it is critical enough for a general purpose lib on a second thought)
>
> That leaves us with several options
>
> a) Leave the prototype code in and sandbox the components permanently
> until the problems are resolved
>
> b) add another component package which has this stuff in to make
> a clear distinction, in this one other portlet problematic components
> can be added as well.
>
> c) Kick it out and loose lots of development functionality in an area
> which has lots of momentum
>
> Option c) does not seem a very good one to me, because, face it proto has
> lots of development momentum and there are myriads of cases where the
> proto lib is a viable choice while only a handful are really problematic.
>
> My suggestion would be to sandbox this stuff for the forseeable future
> until it is clear in which direction proto develops itself.
> And if no clear solutions to the problems are done by the proto devs
> themselves could maybe open a small subproject which is clearly marked
> as problematic in some environments.
>
>
> Werner
>
> Martin Cooper wrote:
> > The main problems with Prototype are:
> >
> > 1) It messes with fundamental built-in JavaScript types. Any time a
> > JavaScript library does this, it causes potential for conflict with
> > other JavaScript libraries. The most obvious problem with Object has
> > indeed been fixed, but there are still several more, and even more being
> > added in 1.4 than are already present in 1.3.1. This type of coding can
> > cause other code in the same page to break either simply because
> > additional functions have been added, thus breaking code that relies on
> > the standard JavaScript objects, or because multiple libraries modify
> > the same built-in types by adding or replacing functions with different
> > code.
> >
> > 2) Lack of namespacing. Namespacing is crucial to co-existing with other
> > JavaScript code. Without it, you are pretty much guaranteed to run into
> > collisions at some point. Prototype defines classes such as Field and
> > Form in the global namespace.. Those are such obvious names that it's
> > not going to be long before someone hits collisions with those in a
> > heterogeneous environment.
> >
> > Now, these problems may sound like no big deal when you're writing a
> > regular web app. You can probably find ways to work around them - when
> > you're in control of the page.
> >
> > But in a portlet environment, these are *really serious issues*. In a
> > portlet environment, you are *not* in control of the page; you are only
> > in control of your portlet(s). Suppose you've written a very cool
> > portlet, using MyFaces, and it uses widgets that in turn use Prototype.
> > You tested your portlet, and you believe it all works just fine. Now one
> > of your paying customers adds it to their corporate portal, and it
> > breaks everything else on the page. That happened because the code in
> > Prototype created issues with JavaScript code being used in other
> > portlets on the page. That is now *your* bug, because the portal was all
> > working until your portlet was added. Your boss asks you why this
> > happened, and your answer is what? That the other portlets weren't
> > written properly? That the MyFaces widgets you were using weren't
> > written properly?
> >
> > You mention that Prototype is used extensively in the Ruby on Rails
> > world. Yes, that's true. But you need to recognise that not only are
> > most people in that world using _only_ Prototype, and its derivatives,
> > but *they are not writing portlets*. They are writing apps with pages
> > over which they have complete control. In those circumstances, you are
> > much less likely to run into problems.
> >
> > That's not the case for MyFaces components. You don't know what your
> > users are going to be doing with them. You have no idea what else might
> > end up on the same page. You can't control that, because they could be
> > used to build portlets, and it's only the final portal user that
> > ultimately constructs the page.
> >
> > So my question to you (collectively, not just Werner ;) is this: Don't
> > you want to build the most robust JSF components that you can? Don't you
> > want to do everything you can to minimise the risk that your users - or
> > their users - will run into problems *because* they're using your
> > components? Do you want to run the risk that people shun MyFaces because
> > (some of) the components are buggy when used in a portal environment, or
> > any other heterogeneous environment?
> >
> > --
> > Martin Cooper
> >
> > PS: A couple of other references:
> >
> > http://blog.metawrap.com/blog/CommentView,guid,42b961d5-b539-4d9a-b1e0-108e546ae3e6.aspx
> > http://www.nabble.com/Re%3A-quick-on-datetime-p2148947.html
> > http://www.nabble.com/Re%3A-quick-on-datetime-p2150570.html
> >
> >
> > On 12/29/05, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>> wrote:
> >
> >     Ok because someone raised this issue, I thought things over and came to
> >     the conclusion a second time, there is no real issue.
> >
> >     First of all, I am not an expert with the newer portlet libraries, but I
> >     have had some extensive knowledge with Jetspeed 1 ( 1.4b3 exactly, which
> >     once I did a bigger portal with)
> >
> >     I do not see a huge deal with using the library in a portlet
> >     environment. At least not bigger than with any other javascript.
> >     But please correct me if I am wrong with it.
> >
> >     First of all. What happens in a portlet environment. Several backend
> >     code related objects are replaced with ones which are then shared over a
> >     central context.
> >     Portlets themselves have for instance their own contexts managing their
> >     own environments.
> >     (In jetspeed1 it was just the jetspeed context which every portlet had
> >     its own and then the global turbine context which itself was derived
> >     from the velocity context of the underlying turbine framework)
> >
> >     The rest is adjusting the events or special events to portlets (like
> >     minimizing, maximizing etc...)
> >
> >     On the frontend side, you basically render the subforms into a single
> >     page by some kind of layouting mechanism (which already means the form
> >     layout has to be adjusted somewhat to the changed environment)
> >
> >     So how does proto could conflict.
> >     a) ID handling, I do not really see a big problem there, portlets have
> >     to behave at the frontend like every other html page, thus
> >     the ids with same components over different portlets, have to adjust, if
> >     not you get bigger problems in other areas than javascript!
> >
> >     b) Conflicting Javascript code. Given the fact that myfaces to my
> >     knowledge already has code in place which prevents double imports of
> >     javascript, there is no conflict on code import level.
> >
> >     The rest is abstracted by the class/object structure to a certain degree
> >     all which basically has to be done, is that the javascript code either
> >     is inlined as event triggers, or that generated objects have to be
> >     adjusted to the component ids (which is mandatory anyway, due to the
> >     fact that you can use two different components of the same type on the
> >     same page)
> >
> >     So I assume proto is way less critical in this area than normal
> >     javascript code which could run into double declaration problems of
> >     functions way easier if programmed sloppily.
> >
> >     The rest of the conflicts is inherent in both pure javascript and
> >     prototyped javascript. (namespace conflicts conflicts due to dyanmic
> >     structures of the language etc...)
> >
> >     c) Prototyes changing of base classes,
> >     yes this is indeed a problem and a problem the devs are aware, one huge
> >     issue has been arisen in the past with the addition of additional
> >     Methods to Object which basically caused in interference with iterations
> >     over object. This issue has been reported and is being or has been (I do
> >     not know the status exactly) addressed.
> >     This seems so far being the most critical problem of the proto lib,
> >     given its high usage percentage (it is the core js lib of rails) and
> >     that it has been actively developed for a while now, others should have
> >     arrived by now, but have not and if have been addressed.
> >     (one issue was a browser memory leak, which martin reported and was
> >     addressed in a short period of time)
> >
> >
> >     I do not see the proto lib as critical problem in a portlet environment,
> >     but given that my knowledge of those environments is somewhat old, you
> >     might correct me.
> >     Moving a code from a normal to a portlet environment never is that easy
> >     you sometimes run into conflicts, but the proto lib seems not like a
> >     showstopper to me. Not bigger or less big than in a normal page
> >     environment and not bigger than any javascript code in a portlet based
> >     system.
> >
> >     I just wanted to drop this food for thought and discussion in here,
> >     because somebody asked the question, and I think it is a serious
> >     concern, and that is basically what I can conclude with my knowledge I
> >     have about this stuff.
> >     (My personal opinions about portlets generally being put aside)
> >
> >
>
>

Re: Prototype library and portlets

[Martin Cooper <ma...@apache.org>]

On 1/3/06, Werner Punz <we...@gmx.at> wrote:
>
> Martin, I checked out the unit tests, they seem to have
> enough info to get startet, some of this stuff is really impressive.
>
> http://archive.dojotoolkit.org/nightly/tests/widget/


There is also the Dojo manual itself:

http://manual.dojotoolkit.org/index.html

Not complete yet, but a lot of useful stuff in there.

but one downside, this stuff seems to be heavily under development
> lots of the unit tests are broken or call deprecated functions.


You just happen to have hit it at a time where the 0.2.1 release went out
and some refactoring has been happening. ;-) The primary focus of the
0.3release will be the widget library, so you'll see a lot coming
quickly in
that regard.

But there seems to be some really nice stuff in there.


Yep. They have some of the sharpest DHTML folks on that project.

--
Martin Cooper


Martin Marinschek wrote:
> > Having looked at Dojo,
> >
> > I need to say that a lot less documentation and samples are available
> > there - is there any way to get up to speed with Dojo easily?
> >
> > Martin, maybe you could help us migrating prototype stuff over to Dojo?
> >
> > regards,
> >
> > Martin
> >
>
>

Re: Prototype library and portlets

[Matthias Wessendorf <mw...@gmail.com>]

Werner-

another interesting project for providing resources is Weblets:
https://weblets.dev.java.net/

-Matthias

On 1/4/06, Adam Winer <aw...@gmail.com> wrote:
> Werner,
>
> ADF has some technology that may be helpful here (when
> it arrives, grumble, grumble...)
>
> http://tinyurl.com/999qe
> http://tinyurl.com/7vn42
>
> Cheers,
> Adam
>
>
>
>
> On 1/3/06, Werner Punz <we...@gmx.at> wrote:
> > Actually this all or nothing or common ground approach is not what I had
> > in mind.
> >
> > What I am thinking of is something along these lines.
> > You already have some kind of dynamic loading infrastructure in there
> > with
> >
> > dojo.require("dojo.a");
> > dojo.require("dojo.b");
> >
> > now the problem as discussed is that this triggers
> > xmlhttp requests and is slow
> >
> > the alternate solution to this dynamic linking is a static linking via
> > an ant build to drop everything into a single file.
> >
> > Also bad, because one time you download a single huge file (well
> > compresset but still)
> >
> > This is a viable approach for a webapp but not for a component library
> > where one component needs part a of dojo and part b and another one
> > needs part a and c.
> >
> > The infrastructure is there to make dynamic includes upon the given
> > needs of the components currently used.
> >
> > So theoretically if only one component is loaded than an include of part
> > a and b is done.
> >
> > If the second one is added an additional one for part c also is done.
> >
> > It is sort of a semi dynamic linking where myfaces adds the needed
> > includes and neither the build system nor the javascript runtime.
> >
> > You get the benefits of both approaches that way, less code download
> > because only the parts needed are loaded and still excellent browser
> > caching, due to standard javascript includes.
> >
> > So my question, does dojo already support such an approach?
> >
> > Werner
> >
> \
>


--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com

Re: Prototype library and portlets

[Craig McClanahan <cr...@apache.org>]

On 1/5/06, Sean Schofield <se...@gmail.com> wrote:
>
> There is also a Shale proposal{1] related to some of this.
>
> Sean
>
> [1] http://www.mail-archive.com/dev@struts.apache.org/msg16683.html


Some code that meets the objectives I've outlined here has been checked in
to Shale as well, and is part of the current nightly builds.  Check out the
javadocs for the "org.apache.shale.remoting" package[1].  In particular, for
static resource serving, this code supports conditional GETs so the client
browser can cache the resources it retrieves ... and that works across pages
too, if they all share a common URL for the resource.  This tends to
dramatically reduce the penalty of using a single large resource (such as
the kitchen sink version of DOJO).

Craig

[1]
http://struts.apache.org/struts-shale/shale-core/apidocs/index.html?org/apache/shale/remoting/package-summary.html

Re: Prototype library and portlets

[Sean Schofield <se...@gmail.com>]

There is also a Shale proposal{1] related to some of this.

Sean

[1] http://www.mail-archive.com/dev@struts.apache.org/msg16683.html


On 1/5/06, Martin Cooper <ma...@apache.org> wrote:
> Sorry for the delay. See below...
>
> On 1/3/06, Werner Punz <we...@gmx.at> wrote:
> > Actually this all or nothing or common ground approach is not what I had
> > in mind.
> >
> > What I am thinking of is something along these lines.
> > You already have some kind of dynamic loading infrastructure in there
> > with
> >
> > dojo.require("dojo.a");
> > dojo.require("dojo.b");
> >
> > now the problem as discussed is that this triggers
> > xmlhttp requests and is slow
> >
> > the alternate solution to this dynamic linking is a static linking via
> > an ant build to drop everything into a single file.
> >
> > Also bad, because one time you download a single huge file (well
> > compresset but still)
>
>  This isn't as bad as you think. You do get one large-ish (not huge ;)
> download, but you save because of only one request to get it, and the
> browser will cache it, so it really is only one download.
>
>  Admittedly, there is a little more pain when using this with JSF because
> the JavaScript will be evaluated on each page load, and JSF is still
> fundamentally page-oriented. There's not much I can do about that. ;-)
>
> > This is a viable approach for a webapp but not for a component library
> > where one component needs part a of dojo and part b and another one
> > needs part a and c.
> >
> > The infrastructure is there to make dynamic includes upon the given
> > needs of the components currently used.
> >
> > So theoretically if only one component is loaded than an include of part
> > a and b is done.
> >
> > If the second one is added an additional one for part c also is done.
> >
> > It is sort of a semi dynamic linking where myfaces adds the needed
> > includes and neither the build system nor the javascript runtime.
>
>  When you refer to "needed includes" here, what do you mean? Are you talking
> about dynamically adding <script src="..."> elements to the page, so that
> the browser then fetches them? If so, then I would be _extremely_ surprised
> if there's any noticeable performance difference between that and what Dojo
> is doing for you, since it ultimately boils down to the same thing.
>
>  If that's not what you mean, then I'm afraid I still don't get it. ;-(
> However, from what Adam said, it sounds like ADF Faces will provide it if
> Dojo doesn't, so you should be all set.
>
>  --
>  Martin Cooper
>
>
>
> > You get the benefits of both approaches that way, less code download
> > because only the parts needed are loaded and still excellent browser
> > caching, due to standard javascript includes.
> >
> > So my question, does dojo already support such an approach?
> >
> > Werner
> >
> >
> >
> >
> >
> >
> >
> > Martin Cooper wrote:
> > > I'm not 100% sure I understand what you're looking for, since I'm not
> > > completely familiar with the way MyFaces components do things today. But
> > > here are a few thoughts:
> > >
> > > 1) If you're going to use Dojo, I would suggest that you either use the
> > > "kitchen sink" profile (that includes everything) or one that includes
> > > what all of the widgets in your library need, rather than trying to load
> > > only what each widget needs. While that would result in a larger dojo.js
> > > file than each widget might need by itself, it means that you get a
> > > one-time download to the browser that is then cached, ultimately leading
> > > to better performance for the page as a whole.
> > >
> > > 2) If you render code on the fly that has something like
> > > 'dojo.require ("foo")', then Dojo will request "foo" and any
> dependencies
> > > of "foo", as it would in development mode, but only if they're not
> > > already loaded into the browser (e.g. through the profile build). While
> > > this isn't what you want as a general solution, it does ensure that your
> > > code doesn't break if something got left out of the profile build. Also
> > > note that "foo" need not be part of Dojo itself, so you can use Dojo to
> > > load your own code too.
> > >
> > > 3) In theory (meaning, I don't know if anyone has tried it ;), you could
> > > generate profile builds on the fly that include only the pieces you
> > > need. This sounds cool, but it's not really practical in the long
> > > run.The problem is that each custom on-the-fly would be a separate
> > > entity as far as the browser is concerned, so you'd be downloading it
> > > every time and it wouldn't be cached. Using the approach in #1 is a
> > > better way of handling this.
> > >
> > > Did I answer your question? I'm not sure. If not, let me know what I'm
> > > missing, and I'll try again. ;-)
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > > On 1/3/06, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>> wrote:
> > >
> > >     Hi Martin, thanks for the clarification,
> > >     but one question, given that myfaces has its own
> > >     loading mechanism which renders the includes dynamically.
> > >     Does dojo have something which could support this.
> > >     The reason why I am asking is, that
> > >     usually the components basically determine themselves
> > >     (with support from myfaces of course) which includes they need.
> > >     And the includes are rendered dynamically away without causing
> > >     double includes.
> > >
> > >     Thus you get the same flexibiliy of the dynamic includes DOJO has
> > >     solved
> > >     on javascript level without the speed tradeoffs of the development
> > >     include of dojo, or the size tradeoffs of the static build of the
> parts
> > >     you need.
> > >     Are there any supportive infrastructures for such a case?
> > >
> > >     Werner
> > >
> > >
> > >
> > >     Martin Cooper wrote:
> > >      >
> > >      >
> > >      > On 1/3/06, *Werner Punz* < werpu@gmx.at <ma...@gmx.at>
> > >     <mailto:werpu@gmx.at <mailto:werpu@gmx.at >>> wrote:
> > >      >
> > >      >     Martin Marinschek wrote:
> > >      >      > In any case we should wait what ADF Faces brings to the
> > >     table with
> > >      >      > regards to javascript, and then see how we merge in the
> > >     best way.
> > >      >      >
> > >      >      > regards,
> > >      >      >
> > >      >      > Martin
> > >      >      >
> > >      >
> > >      >     Well one thing, I noticed with DOJO after checking it out
> > >     extensively is
> > >      >     the slow loading times, since it synchronsously loads itself
> > >     via xmlhttp
> > >      >     request (and probably runs into issues there due to non
> > >     caching of
> > >      >     javascripts within the static browser cache).
> > >      >
> > >      >
> > >      > As you checked it out, you must have missed one of the most
> > >      > sophisticated and powerful parts of the toolkit. ;-) The slow
> loading
> > >      > times you are seeing are almost certainly because you are looking
> > >     at it
> > >      > in "development mode". In development mode, the toolkit figures
> > >     out your
> > >      > dependencies and loads them on the fly. This is cool because you
> > >     don't
> > >      > need to worry about all the indirect needs of your code, and you
> can
> > >      > more quickly get your own code working. It does, however, result
> > >     in the
> > >      > slow load times you noticed. (The files _do_ get cached by the
> > >     browser,
> > >      > though, so that part is not a problem.)
> > >      >
> > >      > In "production mode", you would either deploy a pre-built Dojo
> > >     profile
> > >      > or build and deploy your own custom profile. A profile is
> > >     essentially a
> > >      > definition of which packages you need in your build, and the
> build
> > >      > system uses the same technique as is used in development mode to
> > >      > determine which code to include in the profile build. The build
> > >     system
> > >      > produces a single compressed output file, dojo.js, that contains
> > >     all of
> > >      > the packages you need (and none of the ones you don't), resulting
> in
> > >      > much, much, much faster load times in production mode.
> > >      >
> > >      > Defining a custom profile is really simple, and building it is
> > >     just as
> > >      > simple. Check it out!
> > >      >
> > >      > --
> > >      > Martin Cooper
> > >      >
> > >      >
> > >      >     This is in my opinion unfortunately a huge showstopper for
> > >     the otherwise
> > >      >     excellent lib.
> > >      >     Loading times of 20 seconds for a page using dojo are within
> > >     the normal
> > >      >     timeframe.
> > >      >
> > >      >     Speaking of showstoppers, this is definitely a huge one for
> > >     dojo, and
> > >      >     almost as big or even bigger than the possible interference
> > >     problems of
> > >      >     Prototype, because once you enable dojo your pageloading
> > >     times start to
> > >      >     crawl.
> > >      >
> > >      >     :-(
> > >      >
> > >      >
> > >      >
> > >
> > >
> >
> >
>
>

Re: Prototype library and portlets

[Adam Winer <aw...@gmail.com>]

Werner,

ADF has some technology that may be helpful here (when
it arrives, grumble, grumble...)

http://tinyurl.com/999qe
http://tinyurl.com/7vn42

Cheers,
Adam




On 1/3/06, Werner Punz <we...@gmx.at> wrote:
> Actually this all or nothing or common ground approach is not what I had
> in mind.
>
> What I am thinking of is something along these lines.
> You already have some kind of dynamic loading infrastructure in there
> with
>
> dojo.require("dojo.a");
> dojo.require("dojo.b");
>
> now the problem as discussed is that this triggers
> xmlhttp requests and is slow
>
> the alternate solution to this dynamic linking is a static linking via
> an ant build to drop everything into a single file.
>
> Also bad, because one time you download a single huge file (well
> compresset but still)
>
> This is a viable approach for a webapp but not for a component library
> where one component needs part a of dojo and part b and another one
> needs part a and c.
>
> The infrastructure is there to make dynamic includes upon the given
> needs of the components currently used.
>
> So theoretically if only one component is loaded than an include of part
> a and b is done.
>
> If the second one is added an additional one for part c also is done.
>
> It is sort of a semi dynamic linking where myfaces adds the needed
> includes and neither the build system nor the javascript runtime.
>
> You get the benefits of both approaches that way, less code download
> because only the parts needed are loaded and still excellent browser
> caching, due to standard javascript includes.
>
> So my question, does dojo already support such an approach?
>
> Werner
>
\

Re: Prototype library and portlets

[Martin Cooper <ma...@apache.org>]

Sorry for the delay. See below...

On 1/3/06, Werner Punz <we...@gmx.at> wrote:
>
> Actually this all or nothing or common ground approach is not what I had
> in mind.
>
> What I am thinking of is something along these lines.
> You already have some kind of dynamic loading infrastructure in there
> with
>
> dojo.require("dojo.a");
> dojo.require("dojo.b");
>
> now the problem as discussed is that this triggers
> xmlhttp requests and is slow
>
> the alternate solution to this dynamic linking is a static linking via
> an ant build to drop everything into a single file.
>
> Also bad, because one time you download a single huge file (well
> compresset but still)


This isn't as bad as you think. You do get one large-ish (not huge ;)
download, but you save because of only one request to get it, and the
browser will cache it, so it really is only one download.

Admittedly, there is a little more pain when using this with JSF because the
JavaScript will be evaluated on each page load, and JSF is still
fundamentally page-oriented. There's not much I can do about that. ;-)

This is a viable approach for a webapp but not for a component library
> where one component needs part a of dojo and part b and another one
> needs part a and c.
>
> The infrastructure is there to make dynamic includes upon the given
> needs of the components currently used.
>
> So theoretically if only one component is loaded than an include of part
> a and b is done.
>
> If the second one is added an additional one for part c also is done.
>
> It is sort of a semi dynamic linking where myfaces adds the needed
> includes and neither the build system nor the javascript runtime.


When you refer to "needed includes" here, what do you mean? Are you talking
about dynamically adding <script src="..."> elements to the page, so that
the browser then fetches them? If so, then I would be _extremely_ surprised
if there's any noticeable performance difference between that and what Dojo
is doing for you, since it ultimately boils down to the same thing.

If that's not what you mean, then I'm afraid I still don't get it. ;-(
However, from what Adam said, it sounds like ADF Faces will provide it if
Dojo doesn't, so you should be all set.

--
Martin Cooper


You get the benefits of both approaches that way, less code download
> because only the parts needed are loaded and still excellent browser
> caching, due to standard javascript includes.
>
> So my question, does dojo already support such an approach?
>
> Werner
>
>
>
>
>
>
>
> Martin Cooper wrote:
> > I'm not 100% sure I understand what you're looking for, since I'm not
> > completely familiar with the way MyFaces components do things today. But
> > here are a few thoughts:
> >
> > 1) If you're going to use Dojo, I would suggest that you either use the
> > "kitchen sink" profile (that includes everything) or one that includes
> > what all of the widgets in your library need, rather than trying to load
> > only what each widget needs. While that would result in a larger dojo.js
> > file than each widget might need by itself, it means that you get a
> > one-time download to the browser that is then cached, ultimately leading
> > to better performance for the page as a whole.
> >
> > 2) If you render code on the fly that has something like
> > 'dojo.require("foo")', then Dojo will request "foo" and any dependencies
> > of "foo", as it would in development mode, but only if they're not
> > already loaded into the browser (e.g. through the profile build). While
> > this isn't what you want as a general solution, it does ensure that your
> > code doesn't break if something got left out of the profile build. Also
> > note that "foo" need not be part of Dojo itself, so you can use Dojo to
> > load your own code too.
> >
> > 3) In theory (meaning, I don't know if anyone has tried it ;), you could
> > generate profile builds on the fly that include only the pieces you
> > need. This sounds cool, but it's not really practical in the long
> > run.The problem is that each custom on-the-fly would be a separate
> > entity as far as the browser is concerned, so you'd be downloading it
> > every time and it wouldn't be cached. Using the approach in #1 is a
> > better way of handling this.
> >
> > Did I answer your question? I'm not sure. If not, let me know what I'm
> > missing, and I'll try again. ;-)
> >
> > --
> > Martin Cooper
> >
> >
> > On 1/3/06, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>> wrote:
> >
> >     Hi Martin, thanks for the clarification,
> >     but one question, given that myfaces has its own
> >     loading mechanism which renders the includes dynamically.
> >     Does dojo have something which could support this.
> >     The reason why I am asking is, that
> >     usually the components basically determine themselves
> >     (with support from myfaces of course) which includes they need.
> >     And the includes are rendered dynamically away without causing
> >     double includes.
> >
> >     Thus you get the same flexibiliy of the dynamic includes DOJO has
> >     solved
> >     on javascript level without the speed tradeoffs of the development
> >     include of dojo, or the size tradeoffs of the static build of the
> parts
> >     you need.
> >     Are there any supportive infrastructures for such a case?
> >
> >     Werner
> >
> >
> >
> >     Martin Cooper wrote:
> >      >
> >      >
> >      > On 1/3/06, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>
> >     <mailto:werpu@gmx.at <ma...@gmx.at>>> wrote:
> >      >
> >      >     Martin Marinschek wrote:
> >      >      > In any case we should wait what ADF Faces brings to the
> >     table with
> >      >      > regards to javascript, and then see how we merge in the
> >     best way.
> >      >      >
> >      >      > regards,
> >      >      >
> >      >      > Martin
> >      >      >
> >      >
> >      >     Well one thing, I noticed with DOJO after checking it out
> >     extensively is
> >      >     the slow loading times, since it synchronsously loads itself
> >     via xmlhttp
> >      >     request (and probably runs into issues there due to non
> >     caching of
> >      >     javascripts within the static browser cache).
> >      >
> >      >
> >      > As you checked it out, you must have missed one of the most
> >      > sophisticated and powerful parts of the toolkit. ;-) The slow
> loading
> >      > times you are seeing are almost certainly because you are looking
> >     at it
> >      > in "development mode". In development mode, the toolkit figures
> >     out your
> >      > dependencies and loads them on the fly. This is cool because you
> >     don't
> >      > need to worry about all the indirect needs of your code, and you
> can
> >      > more quickly get your own code working. It does, however, result
> >     in the
> >      > slow load times you noticed. (The files _do_ get cached by the
> >     browser,
> >      > though, so that part is not a problem.)
> >      >
> >      > In "production mode", you would either deploy a pre-built Dojo
> >     profile
> >      > or build and deploy your own custom profile. A profile is
> >     essentially a
> >      > definition of which packages you need in your build, and the
> build
> >      > system uses the same technique as is used in development mode to
> >      > determine which code to include in the profile build. The build
> >     system
> >      > produces a single compressed output file, dojo.js, that contains
> >     all of
> >      > the packages you need (and none of the ones you don't), resulting
> in
> >      > much, much, much faster load times in production mode.
> >      >
> >      > Defining a custom profile is really simple, and building it is
> >     just as
> >      > simple. Check it out!
> >      >
> >      > --
> >      > Martin Cooper
> >      >
> >      >
> >      >     This is in my opinion unfortunately a huge showstopper for
> >     the otherwise
> >      >     excellent lib.
> >      >     Loading times of 20 seconds for a page using dojo are within
> >     the normal
> >      >     timeframe.
> >      >
> >      >     Speaking of showstoppers, this is definitely a huge one for
> >     dojo, and
> >      >     almost as big or even bigger than the possible interference
> >     problems of
> >      >     Prototype, because once you enable dojo your pageloading
> >     times start to
> >      >     crawl.
> >      >
> >      >     :-(
> >      >
> >      >
> >      >
> >
> >
>
>

Re: Prototype library and portlets

[Werner Punz <we...@gmx.at>]

Actually this all or nothing or common ground approach is not what I had 
in mind.

What I am thinking of is something along these lines.
You already have some kind of dynamic loading infrastructure in there
with

dojo.require("dojo.a");
dojo.require("dojo.b");

now the problem as discussed is that this triggers
xmlhttp requests and is slow

the alternate solution to this dynamic linking is a static linking via 
an ant build to drop everything into a single file.

Also bad, because one time you download a single huge file (well 
compresset but still)

This is a viable approach for a webapp but not for a component library 
where one component needs part a of dojo and part b and another one 
needs part a and c.

The infrastructure is there to make dynamic includes upon the given 
needs of the components currently used.

So theoretically if only one component is loaded than an include of part
a and b is done.

If the second one is added an additional one for part c also is done.

It is sort of a semi dynamic linking where myfaces adds the needed 
includes and neither the build system nor the javascript runtime.

You get the benefits of both approaches that way, less code download 
because only the parts needed are loaded and still excellent browser 
caching, due to standard javascript includes.

So my question, does dojo already support such an approach?

Werner







Martin Cooper wrote:
> I'm not 100% sure I understand what you're looking for, since I'm not 
> completely familiar with the way MyFaces components do things today. But 
> here are a few thoughts:
> 
> 1) If you're going to use Dojo, I would suggest that you either use the 
> "kitchen sink" profile (that includes everything) or one that includes 
> what all of the widgets in your library need, rather than trying to load 
> only what each widget needs. While that would result in a larger dojo.js 
> file than each widget might need by itself, it means that you get a 
> one-time download to the browser that is then cached, ultimately leading 
> to better performance for the page as a whole.
> 
> 2) If you render code on the fly that has something like 
> 'dojo.require("foo")', then Dojo will request "foo" and any dependencies 
> of "foo", as it would in development mode, but only if they're not 
> already loaded into the browser (e.g. through the profile build). While 
> this isn't what you want as a general solution, it does ensure that your 
> code doesn't break if something got left out of the profile build. Also 
> note that "foo" need not be part of Dojo itself, so you can use Dojo to 
> load your own code too.
> 
> 3) In theory (meaning, I don't know if anyone has tried it ;), you could 
> generate profile builds on the fly that include only the pieces you 
> need. This sounds cool, but it's not really practical in the long 
> run.The problem is that each custom on-the-fly would be a separate 
> entity as far as the browser is concerned, so you'd be downloading it 
> every time and it wouldn't be cached. Using the approach in #1 is a 
> better way of handling this.
> 
> Did I answer your question? I'm not sure. If not, let me know what I'm 
> missing, and I'll try again. ;-)
> 
> --
> Martin Cooper
> 
> 
> On 1/3/06, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>> wrote:
> 
>     Hi Martin, thanks for the clarification,
>     but one question, given that myfaces has its own
>     loading mechanism which renders the includes dynamically.
>     Does dojo have something which could support this.
>     The reason why I am asking is, that
>     usually the components basically determine themselves
>     (with support from myfaces of course) which includes they need.
>     And the includes are rendered dynamically away without causing
>     double includes.
> 
>     Thus you get the same flexibiliy of the dynamic includes DOJO has
>     solved
>     on javascript level without the speed tradeoffs of the development
>     include of dojo, or the size tradeoffs of the static build of the parts
>     you need.
>     Are there any supportive infrastructures for such a case?
> 
>     Werner
> 
> 
> 
>     Martin Cooper wrote:
>      >
>      >
>      > On 1/3/06, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>
>     <mailto:werpu@gmx.at <ma...@gmx.at>>> wrote:
>      >
>      >     Martin Marinschek wrote:
>      >      > In any case we should wait what ADF Faces brings to the
>     table with
>      >      > regards to javascript, and then see how we merge in the
>     best way.
>      >      >
>      >      > regards,
>      >      >
>      >      > Martin
>      >      >
>      >
>      >     Well one thing, I noticed with DOJO after checking it out
>     extensively is
>      >     the slow loading times, since it synchronsously loads itself
>     via xmlhttp
>      >     request (and probably runs into issues there due to non
>     caching of
>      >     javascripts within the static browser cache).
>      >
>      >
>      > As you checked it out, you must have missed one of the most
>      > sophisticated and powerful parts of the toolkit. ;-) The slow loading
>      > times you are seeing are almost certainly because you are looking
>     at it
>      > in "development mode". In development mode, the toolkit figures
>     out your
>      > dependencies and loads them on the fly. This is cool because you
>     don't
>      > need to worry about all the indirect needs of your code, and you can
>      > more quickly get your own code working. It does, however, result
>     in the
>      > slow load times you noticed. (The files _do_ get cached by the
>     browser,
>      > though, so that part is not a problem.)
>      >
>      > In "production mode", you would either deploy a pre-built Dojo
>     profile
>      > or build and deploy your own custom profile. A profile is
>     essentially a
>      > definition of which packages you need in your build, and the build
>      > system uses the same technique as is used in development mode to
>      > determine which code to include in the profile build. The build
>     system
>      > produces a single compressed output file, dojo.js, that contains
>     all of
>      > the packages you need (and none of the ones you don't), resulting in
>      > much, much, much faster load times in production mode.
>      >
>      > Defining a custom profile is really simple, and building it is
>     just as
>      > simple. Check it out!
>      >
>      > --
>      > Martin Cooper
>      >
>      >
>      >     This is in my opinion unfortunately a huge showstopper for
>     the otherwise
>      >     excellent lib.
>      >     Loading times of 20 seconds for a page using dojo are within
>     the normal
>      >     timeframe.
>      >
>      >     Speaking of showstoppers, this is definitely a huge one for
>     dojo, and
>      >     almost as big or even bigger than the possible interference
>     problems of
>      >     Prototype, because once you enable dojo your pageloading
>     times start to
>      >     crawl.
>      >
>      >     :-(
>      >
>      >
>      >
> 
> 

Re: Prototype library and portlets

[Martin Cooper <ma...@apache.org>]

I'm not 100% sure I understand what you're looking for, since I'm not
completely familiar with the way MyFaces components do things today. But
here are a few thoughts:

1) If you're going to use Dojo, I would suggest that you either use the
"kitchen sink" profile (that includes everything) or one that includes what
all of the widgets in your library need, rather than trying to load only
what each widget needs. While that would result in a larger dojo.js file
than each widget might need by itself, it means that you get a one-time
download to the browser that is then cached, ultimately leading to better
performance for the page as a whole.

2) If you render code on the fly that has something like 'dojo.require("foo")',
then Dojo will request "foo" and any dependencies of "foo", as it would in
development mode, but only if they're not already loaded into the browser (
e.g. through the profile build). While this isn't what you want as a general
solution, it does ensure that your code doesn't break if something got left
out of the profile build. Also note that "foo" need not be part of Dojo
itself, so you can use Dojo to load your own code too.

3) In theory (meaning, I don't know if anyone has tried it ;), you could
generate profile builds on the fly that include only the pieces you need.
This sounds cool, but it's not really practical in the long run.The problem
is that each custom on-the-fly would be a separate entity as far as the
browser is concerned, so you'd be downloading it every time and it wouldn't
be cached. Using the approach in #1 is a better way of handling this.

Did I answer your question? I'm not sure. If not, let me know what I'm
missing, and I'll try again. ;-)

--
Martin Cooper


On 1/3/06, Werner Punz <we...@gmx.at> wrote:
>
> Hi Martin, thanks for the clarification,
> but one question, given that myfaces has its own
> loading mechanism which renders the includes dynamically.
> Does dojo have something which could support this.
> The reason why I am asking is, that
> usually the components basically determine themselves
> (with support from myfaces of course) which includes they need.
> And the includes are rendered dynamically away without causing
> double includes.
>
> Thus you get the same flexibiliy of the dynamic includes DOJO has solved
> on javascript level without the speed tradeoffs of the development
> include of dojo, or the size tradeoffs of the static build of the parts
> you need.
> Are there any supportive infrastructures for such a case?
>
> Werner
>
>
>
> Martin Cooper wrote:
> >
> >
> > On 1/3/06, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>> wrote:
> >
> >     Martin Marinschek wrote:
> >      > In any case we should wait what ADF Faces brings to the table
> with
> >      > regards to javascript, and then see how we merge in the best way.
> >      >
> >      > regards,
> >      >
> >      > Martin
> >      >
> >
> >     Well one thing, I noticed with DOJO after checking it out
> extensively is
> >     the slow loading times, since it synchronsously loads itself via
> xmlhttp
> >     request (and probably runs into issues there due to non caching of
> >     javascripts within the static browser cache).
> >
> >
> > As you checked it out, you must have missed one of the most
> > sophisticated and powerful parts of the toolkit. ;-) The slow loading
> > times you are seeing are almost certainly because you are looking at it
> > in "development mode". In development mode, the toolkit figures out your
> > dependencies and loads them on the fly. This is cool because you don't
> > need to worry about all the indirect needs of your code, and you can
> > more quickly get your own code working. It does, however, result in the
> > slow load times you noticed. (The files _do_ get cached by the browser,
> > though, so that part is not a problem.)
> >
> > In "production mode", you would either deploy a pre-built Dojo profile
> > or build and deploy your own custom profile. A profile is essentially a
> > definition of which packages you need in your build, and the build
> > system uses the same technique as is used in development mode to
> > determine which code to include in the profile build. The build system
> > produces a single compressed output file, dojo.js, that contains all of
> > the packages you need (and none of the ones you don't), resulting in
> > much, much, much faster load times in production mode.
> >
> > Defining a custom profile is really simple, and building it is just as
> > simple. Check it out!
> >
> > --
> > Martin Cooper
> >
> >
> >     This is in my opinion unfortunately a huge showstopper for the
> otherwise
> >     excellent lib.
> >     Loading times of 20 seconds for a page using dojo are within the
> normal
> >     timeframe.
> >
> >     Speaking of showstoppers, this is definitely a huge one for dojo,
> and
> >     almost as big or even bigger than the possible interference problems
> of
> >     Prototype, because once you enable dojo your pageloading times start
> to
> >     crawl.
> >
> >     :-(
> >
> >
> >
>
>

Re: Prototype library and portlets

[Werner Punz <we...@gmx.at>]

Hi Martin, thanks for the clarification,
but one question, given that myfaces has its own
loading mechanism which renders the includes dynamically.
Does dojo have something which could support this.
The reason why I am asking is, that
usually the components basically determine themselves
(with support from myfaces of course) which includes they need.
And the includes are rendered dynamically away without causing
double includes.

Thus you get the same flexibiliy of the dynamic includes DOJO has solved
on javascript level without the speed tradeoffs of the development 
include of dojo, or the size tradeoffs of the static build of the parts 
you need.
Are there any supportive infrastructures for such a case?

Werner



Martin Cooper wrote:
> 
> 
> On 1/3/06, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>> wrote:
> 
>     Martin Marinschek wrote:
>      > In any case we should wait what ADF Faces brings to the table with
>      > regards to javascript, and then see how we merge in the best way.
>      >
>      > regards,
>      >
>      > Martin
>      >
> 
>     Well one thing, I noticed with DOJO after checking it out extensively is
>     the slow loading times, since it synchronsously loads itself via xmlhttp
>     request (and probably runs into issues there due to non caching of
>     javascripts within the static browser cache).
> 
> 
> As you checked it out, you must have missed one of the most 
> sophisticated and powerful parts of the toolkit. ;-) The slow loading 
> times you are seeing are almost certainly because you are looking at it 
> in "development mode". In development mode, the toolkit figures out your 
> dependencies and loads them on the fly. This is cool because you don't 
> need to worry about all the indirect needs of your code, and you can 
> more quickly get your own code working. It does, however, result in the 
> slow load times you noticed. (The files _do_ get cached by the browser, 
> though, so that part is not a problem.)
> 
> In "production mode", you would either deploy a pre-built Dojo profile 
> or build and deploy your own custom profile. A profile is essentially a 
> definition of which packages you need in your build, and the build 
> system uses the same technique as is used in development mode to 
> determine which code to include in the profile build. The build system 
> produces a single compressed output file, dojo.js, that contains all of 
> the packages you need (and none of the ones you don't), resulting in 
> much, much, much faster load times in production mode.
> 
> Defining a custom profile is really simple, and building it is just as 
> simple. Check it out!
> 
> --
> Martin Cooper
> 
> 
>     This is in my opinion unfortunately a huge showstopper for the otherwise
>     excellent lib.
>     Loading times of 20 seconds for a page using dojo are within the normal
>     timeframe.
> 
>     Speaking of showstoppers, this is definitely a huge one for dojo, and
>     almost as big or even bigger than the possible interference problems of
>     Prototype, because once you enable dojo your pageloading times start to
>     crawl.
> 
>     :-(
> 
> 
> 

Re: Prototype library and portlets

[Martin Cooper <ma...@apache.org>]

On 1/3/06, Werner Punz <we...@gmx.at> wrote:
>
> Martin Marinschek wrote:
> > In any case we should wait what ADF Faces brings to the table with
> > regards to javascript, and then see how we merge in the best way.
> >
> > regards,
> >
> > Martin
> >
>
> Well one thing, I noticed with DOJO after checking it out extensively is
> the slow loading times, since it synchronsously loads itself via xmlhttp
> request (and probably runs into issues there due to non caching of
> javascripts within the static browser cache).


As you checked it out, you must have missed one of the most sophisticated
and powerful parts of the toolkit. ;-) The slow loading times you are seeing
are almost certainly because you are looking at it in "development mode". In
development mode, the toolkit figures out your dependencies and loads them
on the fly. This is cool because you don't need to worry about all the
indirect needs of your code, and you can more quickly get your own code
working. It does, however, result in the slow load times you noticed. (The
files _do_ get cached by the browser, though, so that part is not a
problem.)

In "production mode", you would either deploy a pre-built Dojo profile or
build and deploy your own custom profile. A profile is essentially a
definition of which packages you need in your build, and the build system
uses the same technique as is used in development mode to determine which
code to include in the profile build. The build system produces a single
compressed output file, dojo.js, that contains all of the packages you need
(and none of the ones you don't), resulting in much, much, much faster load
times in production mode.

Defining a custom profile is really simple, and building it is just as
simple. Check it out!

--
Martin Cooper


This is in my opinion unfortunately a huge showstopper for the otherwise
> excellent lib.
> Loading times of 20 seconds for a page using dojo are within the normal
> timeframe.
>
> Speaking of showstoppers, this is definitely a huge one for dojo, and
> almost as big or even bigger than the possible interference problems of
> Prototype, because once you enable dojo your pageloading times start to
> crawl.
>
> :-(
>
>
>

Re: Prototype library and portlets

[Werner Punz <we...@gmx.at>]

Martin Marinschek wrote:
> In any case we should wait what ADF Faces brings to the table with
> regards to javascript, and then see how we merge in the best way.
> 
> regards,
> 
> Martin
> 

Well one thing, I noticed with DOJO after checking it out extensively is
the slow loading times, since it synchronsously loads itself via xmlhttp
request (and probably runs into issues there due to non caching of
javascripts within the static browser cache).

This is in my opinion unfortunately a huge showstopper for the otherwise
excellent lib.
Loading times of 20 seconds for a page using dojo are within the normal
timeframe.

Speaking of showstoppers, this is definitely a huge one for dojo, and
almost as big or even bigger than the possible interference problems of
Prototype, because once you enable dojo your pageloading times start to
crawl.

:-(

Re: Prototype library and portlets

[Martin Marinschek <ma...@gmail.com>]

In any case we should wait what ADF Faces brings to the table with
regards to javascript, and then see how we merge in the best way.

regards,

Martin

On 1/3/06, Werner Punz <we...@gmx.at> wrote:
> Martin, I checked out the unit tests, they seem to have
>  enough info to get startet, some of this stuff is really impressive.
>
> http://archive.dojotoolkit.org/nightly/tests/widget/
>
> but one downside, this stuff seems to be heavily under development
> lots of the unit tests are broken or call deprecated functions.
> But there seems to be some really nice stuff in there.
>
>
> Martin Marinschek wrote:
> > Having looked at Dojo,
> >
> > I need to say that a lot less documentation and samples are available
> > there - is there any way to get up to speed with Dojo easily?
> >
> > Martin, maybe you could help us migrating prototype stuff over to Dojo?
> >
> > regards,
> >
> > Martin
> >
>
>


--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: Prototype library and portlets

[Werner Punz <we...@gmx.at>]

Martin, I checked out the unit tests, they seem to have
 enough info to get startet, some of this stuff is really impressive.

http://archive.dojotoolkit.org/nightly/tests/widget/

but one downside, this stuff seems to be heavily under development
lots of the unit tests are broken or call deprecated functions.
But there seems to be some really nice stuff in there.


Martin Marinschek wrote:
> Having looked at Dojo,
> 
> I need to say that a lot less documentation and samples are available
> there - is there any way to get up to speed with Dojo easily?
> 
> Martin, maybe you could help us migrating prototype stuff over to Dojo?
> 
> regards,
> 
> Martin
> 

Re: Prototype library and portlets

[Martin Marinschek <ma...@gmail.com>]

Having looked at Dojo,

I need to say that a lot less documentation and samples are available
there - is there any way to get up to speed with Dojo easily?

Martin, maybe you could help us migrating prototype stuff over to Dojo?

regards,

Martin

On 1/3/06, Werner Punz <we...@gmx.at> wrote:
> The namespacing problem can be resolved with code gens which add
> automatically the namespaces,
>
> the javascript type problem is indeed there
> (although it seems to be not that critical, due to the inherent messy
> nature of javascript itself, but I agree
> it is critical enough for a general purpose lib on a second thought)
>
> That leaves us with several options
>
> a) Leave the prototype code in and sandbox the components permanently
> until the problems are resolved
>
> b) add another component package which has this stuff in to make
> a clear distinction, in this one other portlet problematic components
> can be added as well.
>
> c) Kick it out and loose lots of development functionality in an area
> which has lots of momentum
>
> Option c) does not seem a very good one to me, because, face it proto has
> lots of development momentum and there are myriads of cases where the
> proto lib is a viable choice while only a handful are really problematic.
>
> My suggestion would be to sandbox this stuff for the forseeable future
> until it is clear in which direction proto develops itself.
> And if no clear solutions to the problems are done by the proto devs
> themselves could maybe open a small subproject which is clearly marked
> as problematic in some environments.
>
>
> Werner
>
> Martin Cooper wrote:
> > The main problems with Prototype are:
> >
> > 1) It messes with fundamental built-in JavaScript types. Any time a
> > JavaScript library does this, it causes potential for conflict with
> > other JavaScript libraries. The most obvious problem with Object has
> > indeed been fixed, but there are still several more, and even more being
> > added in 1.4 than are already present in 1.3.1. This type of coding can
> > cause other code in the same page to break either simply because
> > additional functions have been added, thus breaking code that relies on
> > the standard JavaScript objects, or because multiple libraries modify
> > the same built-in types by adding or replacing functions with different
> > code.
> >
> > 2) Lack of namespacing. Namespacing is crucial to co-existing with other
> > JavaScript code. Without it, you are pretty much guaranteed to run into
> > collisions at some point. Prototype defines classes such as Field and
> > Form in the global namespace.. Those are such obvious names that it's
> > not going to be long before someone hits collisions with those in a
> > heterogeneous environment.
> >
> > Now, these problems may sound like no big deal when you're writing a
> > regular web app. You can probably find ways to work around them - when
> > you're in control of the page.
> >
> > But in a portlet environment, these are *really serious issues*. In a
> > portlet environment, you are *not* in control of the page; you are only
> > in control of your portlet(s). Suppose you've written a very cool
> > portlet, using MyFaces, and it uses widgets that in turn use Prototype.
> > You tested your portlet, and you believe it all works just fine. Now one
> > of your paying customers adds it to their corporate portal, and it
> > breaks everything else on the page. That happened because the code in
> > Prototype created issues with JavaScript code being used in other
> > portlets on the page. That is now *your* bug, because the portal was all
> > working until your portlet was added. Your boss asks you why this
> > happened, and your answer is what? That the other portlets weren't
> > written properly? That the MyFaces widgets you were using weren't
> > written properly?
> >
> > You mention that Prototype is used extensively in the Ruby on Rails
> > world. Yes, that's true. But you need to recognise that not only are
> > most people in that world using _only_ Prototype, and its derivatives,
> > but *they are not writing portlets*. They are writing apps with pages
> > over which they have complete control. In those circumstances, you are
> > much less likely to run into problems.
> >
> > That's not the case for MyFaces components. You don't know what your
> > users are going to be doing with them. You have no idea what else might
> > end up on the same page. You can't control that, because they could be
> > used to build portlets, and it's only the final portal user that
> > ultimately constructs the page.
> >
> > So my question to you (collectively, not just Werner ;) is this: Don't
> > you want to build the most robust JSF components that you can? Don't you
> > want to do everything you can to minimise the risk that your users - or
> > their users - will run into problems *because* they're using your
> > components? Do you want to run the risk that people shun MyFaces because
> > (some of) the components are buggy when used in a portal environment, or
> > any other heterogeneous environment?
> >
> > --
> > Martin Cooper
> >
> > PS: A couple of other references:
> >
> > http://blog.metawrap.com/blog/CommentView,guid,42b961d5-b539-4d9a-b1e0-108e546ae3e6.aspx
> > http://www.nabble.com/Re%3A-quick-on-datetime-p2148947.html
> > http://www.nabble.com/Re%3A-quick-on-datetime-p2150570.html
> >
> >
> > On 12/29/05, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>> wrote:
> >
> >     Ok because someone raised this issue, I thought things over and came to
> >     the conclusion a second time, there is no real issue.
> >
> >     First of all, I am not an expert with the newer portlet libraries, but I
> >     have had some extensive knowledge with Jetspeed 1 ( 1.4b3 exactly, which
> >     once I did a bigger portal with)
> >
> >     I do not see a huge deal with using the library in a portlet
> >     environment. At least not bigger than with any other javascript.
> >     But please correct me if I am wrong with it.
> >
> >     First of all. What happens in a portlet environment. Several backend
> >     code related objects are replaced with ones which are then shared over a
> >     central context.
> >     Portlets themselves have for instance their own contexts managing their
> >     own environments.
> >     (In jetspeed1 it was just the jetspeed context which every portlet had
> >     its own and then the global turbine context which itself was derived
> >     from the velocity context of the underlying turbine framework)
> >
> >     The rest is adjusting the events or special events to portlets (like
> >     minimizing, maximizing etc...)
> >
> >     On the frontend side, you basically render the subforms into a single
> >     page by some kind of layouting mechanism (which already means the form
> >     layout has to be adjusted somewhat to the changed environment)
> >
> >     So how does proto could conflict.
> >     a) ID handling, I do not really see a big problem there, portlets have
> >     to behave at the frontend like every other html page, thus
> >     the ids with same components over different portlets, have to adjust, if
> >     not you get bigger problems in other areas than javascript!
> >
> >     b) Conflicting Javascript code. Given the fact that myfaces to my
> >     knowledge already has code in place which prevents double imports of
> >     javascript, there is no conflict on code import level.
> >
> >     The rest is abstracted by the class/object structure to a certain degree
> >     all which basically has to be done, is that the javascript code either
> >     is inlined as event triggers, or that generated objects have to be
> >     adjusted to the component ids (which is mandatory anyway, due to the
> >     fact that you can use two different components of the same type on the
> >     same page)
> >
> >     So I assume proto is way less critical in this area than normal
> >     javascript code which could run into double declaration problems of
> >     functions way easier if programmed sloppily.
> >
> >     The rest of the conflicts is inherent in both pure javascript and
> >     prototyped javascript. (namespace conflicts conflicts due to dyanmic
> >     structures of the language etc...)
> >
> >     c) Prototyes changing of base classes,
> >     yes this is indeed a problem and a problem the devs are aware, one huge
> >     issue has been arisen in the past with the addition of additional
> >     Methods to Object which basically caused in interference with iterations
> >     over object. This issue has been reported and is being or has been (I do
> >     not know the status exactly) addressed.
> >     This seems so far being the most critical problem of the proto lib,
> >     given its high usage percentage (it is the core js lib of rails) and
> >     that it has been actively developed for a while now, others should have
> >     arrived by now, but have not and if have been addressed.
> >     (one issue was a browser memory leak, which martin reported and was
> >     addressed in a short period of time)
> >
> >
> >     I do not see the proto lib as critical problem in a portlet environment,
> >     but given that my knowledge of those environments is somewhat old, you
> >     might correct me.
> >     Moving a code from a normal to a portlet environment never is that easy
> >     you sometimes run into conflicts, but the proto lib seems not like a
> >     showstopper to me. Not bigger or less big than in a normal page
> >     environment and not bigger than any javascript code in a portlet based
> >     system.
> >
> >     I just wanted to drop this food for thought and discussion in here,
> >     because somebody asked the question, and I think it is a serious
> >     concern, and that is basically what I can conclude with my knowledge I
> >     have about this stuff.
> >     (My personal opinions about portlets generally being put aside)
> >
> >
>
>


--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: Prototype library and portlets

[Werner Punz <we...@gmx.at>]

The namespacing problem can be resolved with code gens which add
automatically the namespaces,

the javascript type problem is indeed there
(although it seems to be not that critical, due to the inherent messy
nature of javascript itself, but I agree
it is critical enough for a general purpose lib on a second thought)

That leaves us with several options

a) Leave the prototype code in and sandbox the components permanently
until the problems are resolved

b) add another component package which has this stuff in to make
a clear distinction, in this one other portlet problematic components
can be added as well.

c) Kick it out and loose lots of development functionality in an area
which has lots of momentum

Option c) does not seem a very good one to me, because, face it proto has
lots of development momentum and there are myriads of cases where the
proto lib is a viable choice while only a handful are really problematic.

My suggestion would be to sandbox this stuff for the forseeable future
until it is clear in which direction proto develops itself.
And if no clear solutions to the problems are done by the proto devs
themselves could maybe open a small subproject which is clearly marked
as problematic in some environments.


Werner

Martin Cooper wrote:
> The main problems with Prototype are:
> 
> 1) It messes with fundamental built-in JavaScript types. Any time a
> JavaScript library does this, it causes potential for conflict with
> other JavaScript libraries. The most obvious problem with Object has
> indeed been fixed, but there are still several more, and even more being
> added in 1.4 than are already present in 1.3.1. This type of coding can
> cause other code in the same page to break either simply because
> additional functions have been added, thus breaking code that relies on
> the standard JavaScript objects, or because multiple libraries modify
> the same built-in types by adding or replacing functions with different
> code.
> 
> 2) Lack of namespacing. Namespacing is crucial to co-existing with other
> JavaScript code. Without it, you are pretty much guaranteed to run into
> collisions at some point. Prototype defines classes such as Field and
> Form in the global namespace.. Those are such obvious names that it's
> not going to be long before someone hits collisions with those in a
> heterogeneous environment.
> 
> Now, these problems may sound like no big deal when you're writing a
> regular web app. You can probably find ways to work around them - when
> you're in control of the page.
> 
> But in a portlet environment, these are *really serious issues*. In a
> portlet environment, you are *not* in control of the page; you are only
> in control of your portlet(s). Suppose you've written a very cool
> portlet, using MyFaces, and it uses widgets that in turn use Prototype.
> You tested your portlet, and you believe it all works just fine. Now one
> of your paying customers adds it to their corporate portal, and it
> breaks everything else on the page. That happened because the code in
> Prototype created issues with JavaScript code being used in other
> portlets on the page. That is now *your* bug, because the portal was all
> working until your portlet was added. Your boss asks you why this
> happened, and your answer is what? That the other portlets weren't
> written properly? That the MyFaces widgets you were using weren't
> written properly?
> 
> You mention that Prototype is used extensively in the Ruby on Rails
> world. Yes, that's true. But you need to recognise that not only are
> most people in that world using _only_ Prototype, and its derivatives,
> but *they are not writing portlets*. They are writing apps with pages
> over which they have complete control. In those circumstances, you are
> much less likely to run into problems.
> 
> That's not the case for MyFaces components. You don't know what your
> users are going to be doing with them. You have no idea what else might
> end up on the same page. You can't control that, because they could be
> used to build portlets, and it's only the final portal user that
> ultimately constructs the page.
> 
> So my question to you (collectively, not just Werner ;) is this: Don't
> you want to build the most robust JSF components that you can? Don't you
> want to do everything you can to minimise the risk that your users - or
> their users - will run into problems *because* they're using your
> components? Do you want to run the risk that people shun MyFaces because
> (some of) the components are buggy when used in a portal environment, or
> any other heterogeneous environment?
> 
> --
> Martin Cooper
> 
> PS: A couple of other references:
> 
> http://blog.metawrap.com/blog/CommentView,guid,42b961d5-b539-4d9a-b1e0-108e546ae3e6.aspx
> http://www.nabble.com/Re%3A-quick-on-datetime-p2148947.html
> http://www.nabble.com/Re%3A-quick-on-datetime-p2150570.html
> 
> 
> On 12/29/05, *Werner Punz* <werpu@gmx.at <ma...@gmx.at>> wrote:
> 
>     Ok because someone raised this issue, I thought things over and came to
>     the conclusion a second time, there is no real issue.
> 
>     First of all, I am not an expert with the newer portlet libraries, but I
>     have had some extensive knowledge with Jetspeed 1 ( 1.4b3 exactly, which
>     once I did a bigger portal with)
> 
>     I do not see a huge deal with using the library in a portlet
>     environment. At least not bigger than with any other javascript.
>     But please correct me if I am wrong with it.
> 
>     First of all. What happens in a portlet environment. Several backend
>     code related objects are replaced with ones which are then shared over a
>     central context.
>     Portlets themselves have for instance their own contexts managing their
>     own environments.
>     (In jetspeed1 it was just the jetspeed context which every portlet had
>     its own and then the global turbine context which itself was derived
>     from the velocity context of the underlying turbine framework)
> 
>     The rest is adjusting the events or special events to portlets (like
>     minimizing, maximizing etc...)
> 
>     On the frontend side, you basically render the subforms into a single
>     page by some kind of layouting mechanism (which already means the form
>     layout has to be adjusted somewhat to the changed environment)
> 
>     So how does proto could conflict.
>     a) ID handling, I do not really see a big problem there, portlets have
>     to behave at the frontend like every other html page, thus
>     the ids with same components over different portlets, have to adjust, if
>     not you get bigger problems in other areas than javascript!
> 
>     b) Conflicting Javascript code. Given the fact that myfaces to my
>     knowledge already has code in place which prevents double imports of
>     javascript, there is no conflict on code import level.
> 
>     The rest is abstracted by the class/object structure to a certain degree
>     all which basically has to be done, is that the javascript code either
>     is inlined as event triggers, or that generated objects have to be
>     adjusted to the component ids (which is mandatory anyway, due to the
>     fact that you can use two different components of the same type on the
>     same page)
> 
>     So I assume proto is way less critical in this area than normal
>     javascript code which could run into double declaration problems of
>     functions way easier if programmed sloppily.
> 
>     The rest of the conflicts is inherent in both pure javascript and
>     prototyped javascript. (namespace conflicts conflicts due to dyanmic
>     structures of the language etc...)
> 
>     c) Prototyes changing of base classes,
>     yes this is indeed a problem and a problem the devs are aware, one huge
>     issue has been arisen in the past with the addition of additional
>     Methods to Object which basically caused in interference with iterations
>     over object. This issue has been reported and is being or has been (I do
>     not know the status exactly) addressed.
>     This seems so far being the most critical problem of the proto lib,
>     given its high usage percentage (it is the core js lib of rails) and
>     that it has been actively developed for a while now, others should have
>     arrived by now, but have not and if have been addressed.
>     (one issue was a browser memory leak, which martin reported and was
>     addressed in a short period of time)
> 
> 
>     I do not see the proto lib as critical problem in a portlet environment,
>     but given that my knowledge of those environments is somewhat old, you
>     might correct me.
>     Moving a code from a normal to a portlet environment never is that easy
>     you sometimes run into conflicts, but the proto lib seems not like a
>     showstopper to me. Not bigger or less big than in a normal page
>     environment and not bigger than any javascript code in a portlet based
>     system.
> 
>     I just wanted to drop this food for thought and discussion in here,
>     because somebody asked the question, and I think it is a serious
>     concern, and that is basically what I can conclude with my knowledge I
>     have about this stuff.
>     (My personal opinions about portlets generally being put aside)
> 
> 

Re: Prototype library and portlets

[Martin Cooper <ma...@apache.org>]

The main problems with Prototype are:

1) It messes with fundamental built-in JavaScript types. Any time a
JavaScript library does this, it causes potential for conflict with other
JavaScript libraries. The most obvious problem with Object has indeed been
fixed, but there are still several more, and even more being added in
1.4than are already present in
1.3.1. This type of coding can cause other code in the same page to break
either simply because additional functions have been added, thus breaking
code that relies on the standard JavaScript objects, or because multiple
libraries modify the same built-in types by adding or replacing functions
with different code.

2) Lack of namespacing. Namespacing is crucial to co-existing with other
JavaScript code. Without it, you are pretty much guaranteed to run into
collisions at some point. Prototype defines classes such as Field and Form
in the global namespace.. Those are such obvious names that it's not going
to be long before someone hits collisions with those in a heterogeneous
environment.

Now, these problems may sound like no big deal when you're writing a regular
web app. You can probably find ways to work around them - when you're in
control of the page.

But in a portlet environment, these are *really serious issues*. In a
portlet environment, you are *not* in control of the page; you are only in
control of your portlet(s). Suppose you've written a very cool portlet,
using MyFaces, and it uses widgets that in turn use Prototype. You tested
your portlet, and you believe it all works just fine. Now one of your paying
customers adds it to their corporate portal, and it breaks everything else
on the page. That happened because the code in Prototype created issues with
JavaScript code being used in other portlets on the page. That is now *your*
bug, because the portal was all working until your portlet was added. Your
boss asks you why this happened, and your answer is what? That the other
portlets weren't written properly? That the MyFaces widgets you were using
weren't written properly?

You mention that Prototype is used extensively in the Ruby on Rails world.
Yes, that's true. But you need to recognise that not only are most people in
that world using _only_ Prototype, and its derivatives, but *they are not
writing portlets*. They are writing apps with pages over which they have
complete control. In those circumstances, you are much less likely to run
into problems.

That's not the case for MyFaces components. You don't know what your users
are going to be doing with them. You have no idea what else might end up on
the same page. You can't control that, because they could be used to build
portlets, and it's only the final portal user that ultimately constructs the
page.

So my question to you (collectively, not just Werner ;) is this: Don't you
want to build the most robust JSF components that you can? Don't you want to
do everything you can to minimise the risk that your users - or their users
- will run into problems *because* they're using your components? Do you
want to run the risk that people shun MyFaces because (some of) the
components are buggy when used in a portal environment, or any other
heterogeneous environment?

--
Martin Cooper

PS: A couple of other references:

http://blog.metawrap.com/blog/CommentView,guid,42b961d5-b539-4d9a-b1e0-108e546ae3e6.aspx
http://www.nabble.com/Re%3A-quick-on-datetime-p2148947.html
http://www.nabble.com/Re%3A-quick-on-datetime-p2150570.html


On 12/29/05, Werner Punz <we...@gmx.at> wrote:
>
> Ok because someone raised this issue, I thought things over and came to
> the conclusion a second time, there is no real issue.
>
> First of all, I am not an expert with the newer portlet libraries, but I
> have had some extensive knowledge with Jetspeed 1 (1.4b3 exactly, which
> once I did a bigger portal with)
>
> I do not see a huge deal with using the library in a portlet
> environment. At least not bigger than with any other javascript.
> But please correct me if I am wrong with it.
>
> First of all. What happens in a portlet environment. Several backend
> code related objects are replaced with ones which are then shared over a
> central context.
> Portlets themselves have for instance their own contexts managing their
> own environments.
> (In jetspeed1 it was just the jetspeed context which every portlet had
> its own and then the global turbine context which itself was derived
> from the velocity context of the underlying turbine framework)
>
> The rest is adjusting the events or special events to portlets (like
> minimizing, maximizing etc...)
>
> On the frontend side, you basically render the subforms into a single
> page by some kind of layouting mechanism (which already means the form
> layout has to be adjusted somewhat to the changed environment)
>
> So how does proto could conflict.
> a) ID handling, I do not really see a big problem there, portlets have
> to behave at the frontend like every other html page, thus
> the ids with same components over different portlets, have to adjust, if
> not you get bigger problems in other areas than javascript!
>
> b) Conflicting Javascript code. Given the fact that myfaces to my
> knowledge already has code in place which prevents double imports of
> javascript, there is no conflict on code import level.
>
> The rest is abstracted by the class/object structure to a certain degree
> all which basically has to be done, is that the javascript code either
> is inlined as event triggers, or that generated objects have to be
> adjusted to the component ids (which is mandatory anyway, due to the
> fact that you can use two different components of the same type on the
> same page)
>
> So I assume proto is way less critical in this area than normal
> javascript code which could run into double declaration problems of
> functions way easier if programmed sloppily.
>
> The rest of the conflicts is inherent in both pure javascript and
> prototyped javascript. (namespace conflicts conflicts due to dyanmic
> structures of the language etc...)
>
> c) Prototyes changing of base classes,
> yes this is indeed a problem and a problem the devs are aware, one huge
> issue has been arisen in the past with the addition of additional
> Methods to Object which basically caused in interference with iterations
> over object. This issue has been reported and is being or has been (I do
> not know the status exactly) addressed.
> This seems so far being the most critical problem of the proto lib,
> given its high usage percentage (it is the core js lib of rails) and
> that it has been actively developed for a while now, others should have
> arrived by now, but have not and if have been addressed.
> (one issue was a browser memory leak, which martin reported and was
> addressed in a short period of time)
>
>
> I do not see the proto lib as critical problem in a portlet environment,
> but given that my knowledge of those environments is somewhat old, you
> might correct me.
> Moving a code from a normal to a portlet environment never is that easy
> you sometimes run into conflicts, but the proto lib seems not like a
> showstopper to me. Not bigger or less big than in a normal page
> environment and not bigger than any javascript code in a portlet based
> system.
>
> I just wanted to drop this food for thought and discussion in here,
> because somebody asked the question, and I think it is a serious
> concern, and that is basically what I can conclude with my knowledge I
> have about this stuff.
> (My personal opinions about portlets generally being put aside)
>
>