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)
