> But some code for > selection will be there when the reprint links - finally - will be > introduced to production later this year. It probably won't be nice and > fancy (as in no JavaScript), but useable.
What was the reasoning for not using JS in the OI for this purpose?
I thought the regular webpage was prefered without it, but it was assumed JS would be unavoidable in the OI.
> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: >> But some code for >> selection will be there when the reprint links - finally - will be >> introduced to production later this year. It probably won't be nice and >> fancy (as in no JavaScript), but useable.
> What was the reasoning for not using JS in the OI for this purpose?
Lack of JS knowledge on my part and neither intention nor time nor interest to learn it at this stage.
> I thought the regular webpage was prefered without it, but it was > assumed JS would be unavoidable in the OI.
Sure. We want JS in the OI. But somebody would need to do it.
> Am 13.03.2011 12:08, schrieb Andres Jimenez: >> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: >>> But some code for >>> selection will be there when the reprint links - finally - will be >>> introduced to production later this year. It probably won't be nice and >>> fancy (as in no JavaScript), but useable.
>> What was the reasoning for not using JS in the OI for this purpose?
> Lack of JS knowledge on my part and neither intention nor time nor > interest to learn it at this stage.
>> I thought the regular webpage was prefered without it, but it was >> assumed JS would be unavoidable in the OI.
> Sure. We want JS in the OI. But somebody would need to do it.
> Jochen
> -- > GCD-Tech mailing list - gcd-tech@googlegroups.com > To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/gcd-tech
We should pick a library to use- the most popular in Django-land last I checked (and one of the most popular overall) is jQuery. This will help us with cross-browser compatibility, although it won't magically solve all of those problems.
We also need to be careful about how we add it. The correct way to add JavaScript (based on my experience with another web app over the past three years, learned the hard way) is to keep the JavaScript in files separate from the HTML template files. Link in an external .js that initializes things. This mostly means it should look for HTML elements with particular CSS classes, names or ids and instantiate JS objects or execute JS functions that are relevant for those elements.
The key point is that the interface between the HTML and JavaScript should be the DOM and the CSS. It should *NOT* be scripts embedded in the pages that do specific things. This can be a bit hard to wrap your head around, but works beautifully once you get it. Everything else I've ever tried ended up sucking. A lot.
One important caveat is that you don't want to rely on DOM positioning too much. It's much better to, for instance, instantiate a JavaScript object that adds cool list functionality on a div that has the CSS class "list" than it is to look for the 2nd div on the page, or the div under the div with CSS class X or whatever.
----- Original Message ---- > From: Andres Jimenez <gandre...@gmail.com> > To: gcd-tech@googlegroups.com > Cc: Jochen Garcke <gcdm...@garcke.de> > Sent: Sat, March 12, 2011 5:21:29 PM > Subject: Re: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and re-adding >issues and series
> I am no JS expert at all, but I have used it in the past and would > have no trouble writing a few functions.
> What is needed?
> Andrés
> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: > > Am 13.03.2011 12:08, schrieb Andres Jimenez: > >> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: > >>> But some code for > >>> selection will be there when the reprint links - finally - will be > >>> introduced to production later this year. It probably won't be nice and > >>> fancy (as in no JavaScript), but useable.
> >> What was the reasoning for not using JS in the OI for this purpose?
> > Lack of JS knowledge on my part and neither intention nor time nor > > interest to learn it at this stage.
> >> I thought the regular webpage was prefered without it, but it was > >> assumed JS would be unavoidable in the OI.
> > Sure. We want JS in the OI. But somebody would need to do it.
> > Jochen
> > -- > > GCD-Tech mailing list - gcd-tech@googlegroups.com > > To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > > For more options, visit this group at >http://groups.google.com/group/gcd-tech
> -- > GCD-Tech mailing list - gcd-tech@googlegroups.com > To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/gcd-tech
Henry has ideas how to do searches, filtering and selectiones with JS in a bigger framework, but I don't know too much about that.
But since that is a bigger project, we might reactivate the django-code I did for the reprint selection before that to get going on that front. It might be worth to do some JS routines for that to avoid the workflow over several URLs. But before I look at the code again (after the issue variants) I wouldn't know what can/should be done.
> I am no JS expert at all, but I have used it in the past and would > have no trouble writing a few functions.
> What is needed?
> Andr s
> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: >> Am 13.03.2011 12:08, schrieb Andres Jimenez: >>> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: >>>> But some code for >>>> selection will be there when the reprint links - finally - will be >>>> introduced to production later this year. It probably won't be nice and >>>> fancy (as in no JavaScript), but useable.
>>> What was the reasoning for not using JS in the OI for this purpose?
>> Lack of JS knowledge on my part and neither intention nor time nor >> interest to learn it at this stage.
>>> I thought the regular webpage was prefered without it, but it was >>> assumed JS would be unavoidable in the OI.
>> Sure. We want JS in the OI. But somebody would need to do it.
>> Jochen
>> -- >> GCD-Tech mailing list - gcd-tech@googlegroups.com >> To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com >> For more options, visit this group at http://groups.google.com/group/gcd-tech
Asynchronous queries to a web service? (desired for the long term?)
Long time ago, I used JS to fill select forms (you choose in the first select, generates the contens of the second one). That was easy and required nothing special in the server-side.
> Henry has ideas how to do searches, filtering and selectiones with JS in > a bigger framework, but I don't know too much about that.
> But since that is a bigger project, we might reactivate the django-code > I did for the reprint selection before that to get going on that front. > It might be worth to do some JS routines for that to avoid the workflow > over several URLs. But before I look at the code again (after the issue > variants) I wouldn't know what can/should be done.
> Jochen
> Am 13.03.2011 12:21, schrieb Andres Jimenez: >> I am no JS expert at all, but I have used it in the past and would >> have no trouble writing a few functions.
>> What is needed?
>> Andrés
>> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: >>> Am 13.03.2011 12:08, schrieb Andres Jimenez: >>>> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: >>>>> But some code for >>>>> selection will be there when the reprint links - finally - will be >>>>> introduced to production later this year. It probably won't be nice and >>>>> fancy (as in no JavaScript), but useable.
>>>> What was the reasoning for not using JS in the OI for this purpose?
>>> Lack of JS knowledge on my part and neither intention nor time nor >>> interest to learn it at this stage.
>>>> I thought the regular webpage was prefered without it, but it was >>>> assumed JS would be unavoidable in the OI.
>>> Sure. We want JS in the OI. But somebody would need to do it.
>>> Jochen
>>> -- >>> GCD-Tech mailing list - gcd-tech@googlegroups.com >>> To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com >>> For more options, visit this group at http://groups.google.com/group/gcd-tech
> -- > GCD-Tech mailing list - gcd-tech@googlegroups.com > To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/gcd-tech
Feel free to proceed with your own solution. I can't devote the time to mine that I'd like and we've waited long enough. I want to make sure we don't mix a bunch of JavaScript directly into the HTML templates, and I want to make sure the internal database structure for tracking the more complex relationships in change history make sense. Otherwise I'll back anything that works and is reasonably in line with the overall UI goals.
----- Original Message ---- > From: Jochen Garcke <gcdm...@garcke.de> > To: gcd-tech@googlegroups.com > Sent: Sat, March 12, 2011 5:29:26 PM > Subject: Re: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and re-adding >issues and series
> That is a big question :-)
> Henry has ideas how to do searches, filtering and selectiones with JS in > a bigger framework, but I don't know too much about that.
> But since that is a bigger project, we might reactivate the django-code > I did for the reprint selection before that to get going on that front. > It might be worth to do some JS routines for that to avoid the workflow > over several URLs. But before I look at the code again (after the issue > variants) I wouldn't know what can/should be done.
> Jochen
> Am 13.03.2011 12:21, schrieb Andres Jimenez: > > I am no JS expert at all, but I have used it in the past and would > > have no trouble writing a few functions.
> > What is needed?
> > Andrés
> > 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: > >> Am 13.03.2011 12:08, schrieb Andres Jimenez: > >>> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: > >>>> But some code for > >>>> selection will be there when the reprint links - finally - will be > >>>> introduced to production later this year. It probably won't be nice and > >>>> fancy (as in no JavaScript), but useable.
> >>> What was the reasoning for not using JS in the OI for this purpose?
> >> Lack of JS knowledge on my part and neither intention nor time nor > >> interest to learn it at this stage.
> >>> I thought the regular webpage was prefered without it, but it was > >>> assumed JS would be unavoidable in the OI.
> >> Sure. We want JS in the OI. But somebody would need to do it.
> >> Jochen
> >> -- > >> GCD-Tech mailing list - gcd-tech@googlegroups.com > >> To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > >> For more options, visit this group at >http://groups.google.com/group/gcd-tech
> -- > GCD-Tech mailing list - gcd-tech@googlegroups.com > To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/gcd-tech
> Feel free to proceed with your own solution. I can't devote the time to mine > that I'd like and we've waited long enough. I want to make sure we don't mix a > bunch of JavaScript directly into the HTML templates, and I want to make sure > the internal database structure for tracking the more complex relationships in > change history make sense. Otherwise I'll back anything that works and is > reasonably in line with the overall UI goals.
> -henry
> ----- Original Message ---- >> From: Jochen Garcke <gcdm...@garcke.de> >> To: gcd-tech@googlegroups.com >> Sent: Sat, March 12, 2011 5:29:26 PM >> Subject: Re: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and re-adding >>issues and series
>> That is a big question :-)
>> Henry has ideas how to do searches, filtering and selectiones with JS in >> a bigger framework, but I don't know too much about that.
>> But since that is a bigger project, we might reactivate the django-code >> I did for the reprint selection before that to get going on that front. >> It might be worth to do some JS routines for that to avoid the workflow >> over several URLs. But before I look at the code again (after the issue >> variants) I wouldn't know what can/should be done.
>> Jochen
>> Am 13.03.2011 12:21, schrieb Andres Jimenez: >> > I am no JS expert at all, but I have used it in the past and would >> > have no trouble writing a few functions.
>> > What is needed?
>> > Andrés
>> > 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: >> >> Am 13.03.2011 12:08, schrieb Andres Jimenez: >> >>> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: >> >>>> But some code for >> >>>> selection will be there when the reprint links - finally - will be >> >>>> introduced to production later this year. It probably won't be nice and >> >>>> fancy (as in no JavaScript), but useable.
>> >>> What was the reasoning for not using JS in the OI for this purpose?
>> >> Lack of JS knowledge on my part and neither intention nor time nor >> >> interest to learn it at this stage.
>> >>> I thought the regular webpage was prefered without it, but it was >> >>> assumed JS would be unavoidable in the OI.
>> >> Sure. We want JS in the OI. But somebody would need to do it.
>> >> Jochen
>> >> -- >> >> GCD-Tech mailing list - gcd-tech@googlegroups.com >> >> To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com >> >> For more options, visit this group at >>http://groups.google.com/group/gcd-tech
>> -- >> GCD-Tech mailing list - gcd-tech@googlegroups.com >> To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com >> For more options, visit this group at http://groups.google.com/group/gcd-tech
> -- > GCD-Tech mailing list - gcd-tech@googlegroups.com > To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/gcd-tech
> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: >> For the reprint selection (and others) we need to be able to select a >> different issue/story in a reasonable way in the OI. >> Currently the reprint code doesn't seem to be functionally on my dev >> server, so I can't show you how it is done currently.
> How many "selections" will be needed?
> I guess:
> Contry->Publisher->Series->Issue->Sequence
What I did till now was search directly for a series name and issue number using our normal search routines. From the result list one than could choose an issue. From that a sequence.
> What I did till now was search directly for a series name and issue > number using our normal search routines. From the result list one than > could choose an issue. From that a sequence.
Whatever that returns a pair id->name_to_display will work
My concern is that somebody looking for a series called "Superman" will have too many options to choose from.
I would suggest selecting entities in order (Contry->Publisher->Series->Issue->Sequence). Using AJAX is not too complicated. My main concern would be how fast the autocompletion would happen...
>> What I did till now was search directly for a series name and issue >> number using our normal search routines. From the result list one than >> could choose an issue. From that a sequence.
> Whatever that returns a pair id->name_to_display will work
What I was doing, and I think needs to be done, for the selection of objects is not autocompletion. Precisely because Superman would give too many results and it is difficult to decide which one of the series to take. Therefore in the code for the reprint editing, people would enter series name and issue number at the same time. Optionally publisher, series year. In some way the same info as currently in a reprint link. By using both series and issue number the results is already quite reduced. But still can be large and we need to show reasonable additional information (e.g. publication date).
Selecting down a tree Country->Publisher->Series->Issue->Sequence is not the best option IMHO.
> My concern is that somebody looking for a series called "Superman" > will have too many options to choose from.
> I would suggest selecting entities in order > (Contry->Publisher->Series->Issue->Sequence). Using AJAX is not too > complicated. My main concern would be how fast the autocompletion > would happen...
> Andr s
> 2011/3/13 Andres Jimenez <gandre...@gmail.com>: >> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>:
>>> What I did till now was search directly for a series name and issue >>> number using our normal search routines. From the result list one than >>> could choose an issue. From that a sequence.
>> Whatever that returns a pair id->name_to_display will work
I have an intense hatred of autocomplete. It is a *HORRIBLE* performance suck, whether you try to do it client-side or with server calls (different kinds of performance suck, but lots of suck either way). Totally killed the usability of the other app I work on. It's pretty much the last thing I'd recommend spending time on. If y'all want it, go ahead, but pay a lot of attention to performance. You can't just slap some autocomplete library on a form and expect your system to handle it.
----- Original Message ---- > From: Jochen Garcke <gcdm...@garcke.de> > To: gcd-tech@googlegroups.com > Sent: Sat, March 12, 2011 8:31:24 PM > Subject: Re: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and re-adding >issues and series
> What I was doing, and I think needs to be done, for the selection of > objects is not autocompletion. Precisely because Superman would give too > many results and it is difficult to decide which one of the series to take. > Therefore in the code for the reprint editing, people would enter series > name and issue number at the same time. Optionally publisher, series > year. In some way the same info as currently in a reprint link. > By using both series and issue number the results is already quite > reduced. But still can be large and we need to show reasonable > additional information (e.g. publication date).
> Selecting down a tree Country->Publisher->Series->Issue->Sequence is not > the best option IMHO.
> Jochen
> Am 13.03.2011 14:29, schrieb Andres Jimenez: > > What if we use this as our first approach to autocomplete?
> > My concern is that somebody looking for a series called "Superman" > > will have too many options to choose from.
> > I would suggest selecting entities in order > > (Contry->Publisher->Series->Issue->Sequence). Using AJAX is not too > > complicated. My main concern would be how fast the autocompletion > > would happen...
> >>> What I did till now was search directly for a series name and issue > >>> number using our normal search routines. From the result list one than > >>> could choose an issue. From that a sequence.
> >> Whatever that returns a pair id->name_to_display will work
> -- > GCD-Tech mailing list - gcd-tech@googlegroups.com > To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/gcd-tech
The point of the way I recommend doing JavaScript is that the JS has nothing to do with the server except: * Knowing what URL to hit for requests if JS is initiating any requests * Knowing what CSS classes and HTML elements to look for when hooking on extended functionality * Knowing what data format is being used if the JS is reading any responses and using the data to generate new HTML. If the data format is HTML, the JS just needs to know where to stuff the HTML.
This way, the JavaScript programmer doesn't need to know anything at all about the server side, assuming there is good communication with whoever is writing the server side code and templates.
----- Original Message ---- > From: Andres Jimenez <gandre...@gmail.com> > To: gcd-tech@googlegroups.com > Cc: Henry Andrews <andrews_he...@yahoo.com> > Sent: Sat, March 12, 2011 6:03:59 PM > Subject: Re: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and re-adding >issues and series
> The JS involved is simplle and would take probably only hours, but I > am afraid I would waste too much time trying to communicate with > Django.
> 2011/3/13 Henry Andrews <andrews_he...@yahoo.com>: > > Feel free to proceed with your own solution. I can't devote the time to >mine > > that I'd like and we've waited long enough. I want to make sure we don't >mix a > > bunch of JavaScript directly into the HTML templates, and I want to make >sure > > the internal database structure for tracking the more complex relationships >in > > change history make sense. Otherwise I'll back anything that works and is > > reasonably in line with the overall UI goals.
> > -henry
> > ----- Original Message ---- > >> From: Jochen Garcke <gcdm...@garcke.de> > >> To: gcd-tech@googlegroups.com > >> Sent: Sat, March 12, 2011 5:29:26 PM > >> Subject: Re: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and >re-adding > >>issues and series
> >> That is a big question :-)
> >> Henry has ideas how to do searches, filtering and selectiones with JS in > >> a bigger framework, but I don't know too much about that.
> >> But since that is a bigger project, we might reactivate the django-code > >> I did for the reprint selection before that to get going on that front. > >> It might be worth to do some JS routines for that to avoid the workflow > >> over several URLs. But before I look at the code again (after the issue > >> variants) I wouldn't know what can/should be done.
> >> Jochen
> >> Am 13.03.2011 12:21, schrieb Andres Jimenez: > >> > I am no JS expert at all, but I have used it in the past and would > >> > have no trouble writing a few functions.
> >> > What is needed?
> >> > Andrés
> >> > 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: > >> >> Am 13.03.2011 12:08, schrieb Andres Jimenez: > >> >>> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>: > >> >>>> But some code for > >> >>>> selection will be there when the reprint links - finally - will be > >> >>>> introduced to production later this year. It probably won't be nice >and > >> >>>> fancy (as in no JavaScript), but useable.
> >> >>> What was the reasoning for not using JS in the OI for this purpose?
> >> >> Lack of JS knowledge on my part and neither intention nor time nor > >> >> interest to learn it at this stage.
> >> >>> I thought the regular webpage was prefered without it, but it was > >> >>> assumed JS would be unavoidable in the OI.
> >> >> Sure. We want JS in the OI. But somebody would need to do it.
> >> >> Jochen
> >> >> -- > >> >> GCD-Tech mailing list - gcd-tech@googlegroups.com > >> >> To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > >> >> For more options, visit this group at > >>http://groups.google.com/group/gcd-tech
> >> -- > >> GCD-Tech mailing list - gcd-tech@googlegroups.com > >> To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > >> For more options, visit this group at >http://groups.google.com/group/gcd-tech
> > -- > > GCD-Tech mailing list - gcd-tech@googlegroups.com > > To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > > For more options, visit this group at >http://groups.google.com/group/gcd-tech
So, since I doubt the useability of autocomplete at least for the object selection scenario (it might be different in other areas of the OI) and it is performance suck (which I kind of expected) following this track doesn't seem worthwhile for object selection..
> I have an intense hatred of autocomplete. It is a *HORRIBLE* performance suck, > whether you try to do it client-side or with server calls (different kinds of > performance suck, but lots of suck either way). Totally killed the usability of > the other app I work on. It's pretty much the last thing I'd recommend spending > time on. If y'all want it, go ahead, but pay a lot of attention to performance. > You can't just slap some autocomplete library on a form and expect your system > to handle it.
> -henry
> ----- Original Message ---- >> From: Jochen Garcke <gcdm...@garcke.de> >> To: gcd-tech@googlegroups.com >> Sent: Sat, March 12, 2011 8:31:24 PM >> Subject: Re: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and re-adding >> issues and series
>> What I was doing, and I think needs to be done, for the selection of >> objects is not autocompletion. Precisely because Superman would give too >> many results and it is difficult to decide which one of the series to take. >> Therefore in the code for the reprint editing, people would enter series >> name and issue number at the same time. Optionally publisher, series >> year. In some way the same info as currently in a reprint link. >> By using both series and issue number the results is already quite >> reduced. But still can be large and we need to show reasonable >> additional information (e.g. publication date).
>> Selecting down a tree Country->Publisher->Series->Issue->Sequence is not >> the best option IMHO.
>> Jochen
>> Am 13.03.2011 14:29, schrieb Andres Jimenez: >>> What if we use this as our first approach to autocomplete?
>>> My concern is that somebody looking for a series called "Superman" >>> will have too many options to choose from.
>>> I would suggest selecting entities in order >>> (Contry->Publisher->Series->Issue->Sequence). Using AJAX is not too >>> complicated. My main concern would be how fast the autocompletion >>> would happen...
>>> Andr s
>>> 2011/3/13 Andres Jimenez <gandre...@gmail.com>: >>>> 2011/3/13 Jochen Garcke <gcdm...@garcke.de>:
>>>>> What I did till now was search directly for a series name and issue >>>>> number using our normal search routines. From the result list one than >>>>> could choose an issue. From that a sequence.
>>>> Whatever that returns a pair id->name_to_display will work
>> -- >> GCD-Tech mailing list - gcd-tech@googlegroups.com >> To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com >> For more options, visit this group at http://groups.google.com/group/gcd-tech
> Therefore in the code for the reprint editing, people would enter series > name and issue number at the same time. Optionally publisher, series > year. In some way the same info as currently in a reprint link.
If we enter different types of data in a search field, we will need to "teach" our users in which order information needs to be enteres (just like it is needed with the reprime links).
I still think we need to either base the whole "find-the-object-thing" in an advanced search (typing a series' name and issue number and show ALL ocurrences ) or request our indexers to insert each piece of data in the proper order.
Would be acceptable to show a simpler versión of the advanced search in a layer? The search's results would show a link to select the found issue or sequence.
The layer would be displayed after clicking on a link.
I believe that what you are proposing is the design I favor, Andrés. The user clicks on a button, a layer is presented (on the same page, floating above the regular view, but not a separate OS window) that shows something resembling advanced search. Probably just a few fields- whatever is most necessary for finding the object in question. For reprints, series name, year began, publisher name, issue number, volume number, plus story title (and maybe type?). The user runs the search, the panel refreshes with results, and the user selects the desired result. The user can refine the search and move from page to page of search results all within that panel.
This pattern will solve the vast majority of many-to-many relation UI problems and not require the writing a separate parser for various formats. It can be done in such a way that if you get an exact match then you can choose as a search option to automatically select it (kind of like Google's "I'm feeling lucky" button).
Having implemented something like this before (but not in jQuery), the biggest pain was getting the search+result list interface to be sufficiently self-contained that you could have more than one of them on a given interactive page.
----- Original Message ---- > From: Andres Jimenez <gandre...@gmail.com> > To: "gcd-tech@googlegroups.com" <gcd-tech@googlegroups.com> > Cc: Jochen Garcke <gcdm...@garcke.de> > Sent: Sun, April 3, 2011 11:33:03 AM > Subject: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and re-adding >issues and series
> > Therefore in the code for the reprint editing, people would enter series > > name and issue number at the same time. Optionally publisher, series > > year. In some way the same info as currently in a reprint link.
> If we enter different types of data in a search field, we will need to > "teach" our users in which order information needs to be enteres (just > like it is needed with the reprime links).
> I still think we need to either base the whole "find-the-object-thing" > in an advanced search (typing a series' name and issue number and show > ALL ocurrences ) or request our indexers to insert each piece of data > in the proper order.
> Would be acceptable to show a simpler versión of the advanced search > in a layer? The search's results would show a link to select the found > issue or sequence.
> The layer would be displayed after clicking on a link.
> -- > GCD-Tech mailing list - gcd-tech@googlegroups.com > To unsubscribe send email to gcd-tech+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/gcd-tech
