myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <we...@gmx.at>
Subject Re: Two Input Suggests (Lets not go down this road again)
Date Fri, 08 Jul 2005 23:18:03 GMT
Sean Schofield wrote:
> I noticed there is a new inputSuggest by Werner added to the sandbox. 

Not really that new, it has been in the wild for almost three weeks
It was on sourceforge, and somebody must have moved it into the main 
codebase on svn.
(I do not have write access there yet)

> I've experimented with it a little bit on his website but I haven't
> looked behind the hood.  Matt Blum and I have our own verison of
> inputSuggest.
>
> I think its fine to have two similar components in the sandbox but I
> think we should figure out how to merge these two components before
> leaving the sandbox.  I'd hate to have a situation where we have two
> similar components where one will do.
> 
Yes I have been thinking around this isse as well as I noticed your 
input suggest two days ago...

The main problem was, why this has happend, I developed my input suggest
for my last project and since I am not a commiter or maintainer, I moved 
my stuff to the sourceforge project.
Somebody must have moved the codebase to the official sandbox by now.
(I am still working on the sourceforge codebase, currently doing a major 
rewrite of the underlying javascript, which will be much better then)

It was a mere coincidence that this has happened given that the input 
suggest was basically refactored out of an ongoing project of mine.


> The inputSuggest that Matt and I contributed does not support Ajax yet
> but it has a few extras that the other one doesn't seem to have. 
> Werner's has Ajax support but is missing some of these extras.  So it
> seems like there could be a meeting of the minds.
> 
Yes definitely... I checked your scripts, first of all they are much 
better than the old ones I had, you also added a scroller and from what 
I could gather from a quick glance on the sources a real type ahead preview.

I only moved the ajax code from the blueprints and not even that well, 
because I was on a tight schedule and fixed them to my needs.
The new Version I have is much better and also easier to modify and 
integrate with your stuff.

There is currently a javascript in the webapp dir in sourceforge which 
is in a semi working state, which shows the stuff.

Basically the integration of both codebases at least on the javascript 
side of things is much easier that way, because I adhere, to a strict 
MVC (view controller actually not a real model yet), which means you can 
derive from the controller class and add additional controller handling, 
and you can derive from the view for additonal view handling like a 
scroller.

> I don't have a lot of time in the near term to look at this.  Perhaps
> Matt and Werner should discuss?  (Discussions should be on the
> dev-list please.)   I will try and take a closer look at Werner's
> component and also at what Craig is doing to support Ajax with Shale
> but that will take some time.
> 
Willing to help, as my time permits...


> In general I think we need a overall strategy on how we are going to
> support Ajax with MyFaces and how we can avoid duplication with the
> Shale project.
>
Well there are several points...
a) first of all how do we handle the whole javascript issue for dynamic 
components more tightly integrated, so that we avoid code doupling (AJAX
is heavily javascript centric), so are the effects which are built on 
top of Prototype

b) how do we handle AJAX generally, there are some really good libs in 
the wild which I discovered
while working on my stuff, I settled down for now for the prototype lib, 
which builds a basic oo foundation around Javascript and adds lots of 
effects, but it is only half usable for easy ajax, DWR is much easier in 
that regards because it also automates the backend tier to a big degree, 
but the downside of that one is yet another set of config files thus I 
shied away from it.

Also for ajax we probably have to integrate really strongly on the 
backend side with shale.

What I did was basically to implement a simple event system which hooks 
nicely into jsf without breaking any JSF related patterns.
But I did not have time to flesh it out fully, it is more like a proof 
of concept, no big deal to move to something more fleshed out in the 
long run. I needed something fast which permitted to implement backends 
very swiftly for exactly that component.
Because I had to implement around 10 backends for my last project in 
around a day or so.
So it is more or less usable code, but replacing it probably would 
result in something better, more fleshed out.

> sean
> 
> ps The client-side tab by Werner (also on his site) looks very
> promising.  It could use some dressing up but the basic functionality
> (and the client-side nature) is exactly what we need IMO.
> 
yes... I only pushed it as far as I needed it for my project and dumped 
it into the wild for others to have and improve.
I love the client tabs, they save lots of roundtrips especially for more 
complicated masks.

I do also not see a big issue in integrating them into the existing
codebase, because they do not add any significant functionality on the 
component level, they just are a new renderer a fix on top of the old 
codebase and a bunch of javascripts.

Btw... another question, how can you get write access to the sandbox? I 
am still sort of stuck on sourceforge and want to slowly move my stuff 
over. (I do not mind if others do it, however, like it happened with the 
input suggest)



Mime
View raw message