Two Input Suggests (Lets not go down this road again)

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

I noticed there is a new inputSuggest by Werner added to the sandbox. 
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.

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.

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.

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.

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.

Re: Two Input Suggests (Lets not go down this road again)

[Craig McClanahan <cr...@gmail.com>]

On 7/8/05, Sean Schofield <se...@gmail.com> wrote:
> 
> 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.

For Shale, my intention is to focus on the server side support that
any AJAX solution needs, not on AJAX-enabled JSF components.  After
all, no matter what sort of JavaScript library you're using on the
front end (or whether you coded that JavaScript explicity or a
component did it for you), SOMEBODY has to hook the incoming requests
up to the corresponding business logic, perform updates to the model
tier if requested, pull data out of the model, and format it as a
response.  Since that's what a web framework does for standard form
submit requests, it makes sense to bring the same capabilities to the
back end behind all the asynchronous data-oriented AJAX requests that
everybody is building.

> 
> sean
> 

Craig

Re: Two Input Suggests (Lets not go down this road again)

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

Martin Marinschek wrote:
> Well, for my current project I definitely need to jump on that
> bandwaggon, so I will keep experimenting.
> 
> Let's see where we get to after some time!
> 
> regards,
> 
> Martin
> 
Martin, if you need help with some of my code on sourceforge
feel free to contact me anytime on the phone...

Btw... thanks for doing that :-)

Werner

Re: Two Input Suggests (Lets not go down this road again)

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

Well, for my current project I definitely need to jump on that
bandwaggon, so I will keep experimenting.

Let's see where we get to after some time!

regards,

Martin

On 7/10/05, Sean Schofield <se...@gmail.com> wrote:
> > P.S.:
> >
> > Sean, why I couldn't extend your component right away: the choices are
> > in the case of your inputSuggest given out to the user by including
> > several select items in the inputSuggest tag - imagine a hundred
> > thousand streets in a database, you wouldn't be able to do that with
> > selectItems included in the main tag.
> 
> What do you mean "extend"?  Do you mean that in the java keyword
> sense?  I certainly have no problems extending or modifying
> inputSuggest if that's what you're asking.
> 
> I agree that for large data sets you would need AJAX.  AJAX also
> complicates things so my goal was to get it nice and tight before
> adding AJAX.
> 
> In general I think we need to take a long look at AJAX before jumping
> on that bandwagon.  I know it is the latest buzzword but personally I
> would prefer a solid inputSuggest that worked perfectly with limited
> sets then an rough one that worked with larger sets.  inputSuggest is
> brand new and there are still plenty of issues to be discovered as
> people use it, so IMO we have not reached that goal yet.
> 
> > Martin
> 
> sean
>

Re: Two Input Suggests (Lets not go down this road again)

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

> P.S.:
> 
> Sean, why I couldn't extend your component right away: the choices are
> in the case of your inputSuggest given out to the user by including
> several select items in the inputSuggest tag - imagine a hundred
> thousand streets in a database, you wouldn't be able to do that with
> selectItems included in the main tag.

What do you mean "extend"?  Do you mean that in the java keyword
sense?  I certainly have no problems extending or modifying
inputSuggest if that's what you're asking.

I agree that for large data sets you would need AJAX.  AJAX also
complicates things so my goal was to get it nice and tight before
adding AJAX.

In general I think we need to take a long look at AJAX before jumping
on that bandwagon.  I know it is the latest buzzword but personally I
would prefer a solid inputSuggest that worked perfectly with limited
sets then an rough one that worked with larger sets.  inputSuggest is
brand new and there are still plenty of issues to be discovered as
people use it, so IMO we have not reached that goal yet.

> Martin

sean

Re: Two Input Suggests (Lets not go down this road again)

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

P.S.:

Sean, why I couldn't extend your component right away: the choices are
in the case of your inputSuggest given out to the user by including
several select items in the inputSuggest tag - imagine a hundred
thousand streets in a database, you wouldn't be able to do that with
selectItems included in the main tag.

regards,

Martin

On 7/9/05, Martin Marinschek <ma...@gmail.com> wrote:
> Stay cool, stay calm, everyone,
> 
> I just had to move that in as I am experimenting a little on the Ajax
> stuff. I basically took some of Werner's ideas, merged that with the
> prototype library, and tried to follow what Sean has laid out for his
> inputSuggest. But please wait until I get closer to my goal of getting
> used to AJAX, and we can then start off discussing about what to do
> with the components.
> 
> I will especially be experimenting what to do about the
> backend-integration. Right now, also after talking to Manfred and
> Thomas, there is still some fog in my mind which needs to clear, but I
> think I might basically let each Ajax request run through the faces
> request/response and stop dead at a phase listener which then decides
> what will be rendered out.
> 
> Regard this only as a moving target right now!
> 
> regards,
> 
> Martin
> 
> 
> 
> On 7/9/05, Bruno Aranda <br...@gmail.com> wrote:
> > I am sure we will reach a consensus on this and get the best component
> > possible. I give you my opinion in both components, not knowing the
> > insights of any of them.
> > Regarding the name of the component, I like more the name
> > 'inputSuggest', because it is easy to remember and someone who do not
> > know what this component does will associate directly to Google's
> > suggest. I like more the suggestions scroll-box of the Matt-Sean
> > component as it seams cleaner, but I like the input box coloring of
> > Werner's component. Both of them are great so the result of the merge
> > would be even greater!
> >
> > Regards,
> >
> > Bruno
> >
> > - Suggestions display: I like more the scroll box of the
> > 2005/7/9, Werner Punz <we...@gmx.at>:
> > > Werner Punz wrote:
> > > >
> > > > Actually just checked the sources I got in today from the svn sandbox,
> > > > there is nothing from me left anymore :-D
> > > > Command back, that suff is from someone else, but they placed the code
> > > > for the autocomplete on top of the prototype which is excellent
> > > >
> > > >
> > > Btw... another thing, I checked the code for the new autocomplete
> > > Javascripts, it is absolutely excellent.
> > > Unfortunately it has the same component leak problems like the effects.
> > >
> > > (I am not sure, but I think the guy who wrote this stuff,
> > > basically must be the same one I contacted yesterday, because of a
> > > component leak problem in the basic effects code)
> > >
> > >
> >
>

Re: Two Input Suggests (Lets not go down this road again)

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

Stay cool, stay calm, everyone,

I just had to move that in as I am experimenting a little on the Ajax
stuff. I basically took some of Werner's ideas, merged that with the
prototype library, and tried to follow what Sean has laid out for his
inputSuggest. But please wait until I get closer to my goal of getting
used to AJAX, and we can then start off discussing about what to do
with the components.

I will especially be experimenting what to do about the
backend-integration. Right now, also after talking to Manfred and
Thomas, there is still some fog in my mind which needs to clear, but I
think I might basically let each Ajax request run through the faces
request/response and stop dead at a phase listener which then decides
what will be rendered out.

Regard this only as a moving target right now!

regards,

Martin



On 7/9/05, Bruno Aranda <br...@gmail.com> wrote:
> I am sure we will reach a consensus on this and get the best component
> possible. I give you my opinion in both components, not knowing the
> insights of any of them.
> Regarding the name of the component, I like more the name
> 'inputSuggest', because it is easy to remember and someone who do not
> know what this component does will associate directly to Google's
> suggest. I like more the suggestions scroll-box of the Matt-Sean
> component as it seams cleaner, but I like the input box coloring of
> Werner's component. Both of them are great so the result of the merge
> would be even greater!
> 
> Regards,
> 
> Bruno
> 
> - Suggestions display: I like more the scroll box of the
> 2005/7/9, Werner Punz <we...@gmx.at>:
> > Werner Punz wrote:
> > >
> > > Actually just checked the sources I got in today from the svn sandbox,
> > > there is nothing from me left anymore :-D
> > > Command back, that suff is from someone else, but they placed the code
> > > for the autocomplete on top of the prototype which is excellent
> > >
> > >
> > Btw... another thing, I checked the code for the new autocomplete
> > Javascripts, it is absolutely excellent.
> > Unfortunately it has the same component leak problems like the effects.
> >
> > (I am not sure, but I think the guy who wrote this stuff,
> > basically must be the same one I contacted yesterday, because of a
> > component leak problem in the basic effects code)
> >
> >
>

Re: Two Input Suggests (Lets not go down this road again)

[Bruno Aranda <br...@gmail.com>]

I am sure we will reach a consensus on this and get the best component
possible. I give you my opinion in both components, not knowing the
insights of any of them.
Regarding the name of the component, I like more the name
'inputSuggest', because it is easy to remember and someone who do not
know what this component does will associate directly to Google's
suggest. I like more the suggestions scroll-box of the Matt-Sean
component as it seams cleaner, but I like the input box coloring of
Werner's component. Both of them are great so the result of the merge
would be even greater!

Regards,

Bruno

- Suggestions display: I like more the scroll box of the 
2005/7/9, Werner Punz <we...@gmx.at>:
> Werner Punz wrote:
> >
> > Actually just checked the sources I got in today from the svn sandbox,
> > there is nothing from me left anymore :-D
> > Command back, that suff is from someone else, but they placed the code
> > for the autocomplete on top of the prototype which is excellent
> >
> >
> Btw... another thing, I checked the code for the new autocomplete
> Javascripts, it is absolutely excellent.
> Unfortunately it has the same component leak problems like the effects.
> 
> (I am not sure, but I think the guy who wrote this stuff,
> basically must be the same one I contacted yesterday, because of a
> component leak problem in the basic effects code)
> 
>

Re: Two Input Suggests (Lets not go down this road again)

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

Werner Punz wrote:
> 
> Actually just checked the sources I got in today from the svn sandbox,
> there is nothing from me left anymore :-D
> Command back, that suff is from someone else, but they placed the code
> for the autocomplete on top of the prototype which is excellent
> 
> 
Btw... another thing, I checked the code for the new autocomplete 
Javascripts, it is absolutely excellent.
Unfortunately it has the same component leak problems like the effects.

(I am not sure, but I think the guy who wrote this stuff,
basically must be the same one I contacted yesterday, because of a 
component leak problem in the basic effects code)

Re: Two Input Suggests (Lets not go down this road again)

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

Actually just checked the sources I got in today from the svn sandbox,
there is nothing from me left anymore :-D
Command back, that suff is from someone else, but they placed the code
for the autocomplete on top of the prototype which is excellent

Re: Two Input Suggests (Lets not go down this road again)

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

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)