On Wed, Jan 26, 2011 at 5:19 PM, ejc <[email protected]> wrote: > This sounds like a good solution for now. I was starting to think > about what it would take to rewrite the comet timeline. Like you > indicated before, it's not trivial. I suspect that more recent > versions of lift have some additions to make this easier. The other > day I was looking through JIRA to find unassigned bugs to work on and > found this one: > > https://issues.apache.org/jira/browse/ESME-268 > > I seems this bug could be fixed with a rewrite. How does it sound to > plan this for 1.3 or something? I'd be willing to look through bugs > and try to identify ones that could be fixed in this manner.
That would be great. > > Comments? > > Thanks, > Eric > > > On Wed, Jan 26, 2011 at 7:45 AM, Ethan Jewett <[email protected]> wrote: >> On Wed, Jan 26, 2011 at 4:35 PM, Richard Hirsch <[email protected]> >> wrote: >>> On Wed, Jan 26, 2011 at 2:30 PM, Ethan Jewett <[email protected]> wrote: >>>> 1. Use only relative paths, which would probably involve having each >>>> page set a JS variable to the value of the relative base path from its >>>> location (e.g. "../..") >>> >>> That would be perfect but do you have ideas how to do this? Any ideas? >>> >>> The current code committed to JIRA is still a work around and doesn't >>> really work. Shall I do a rollback to the old code - at least it >>> worked in jetty. >> >> In each snippet that uses a comet timeline, manually enter a script >> element in the template that contains the javascript: >> >> var relative_root_path = "../" >> >> This is an example for a snippet that is "one level deep", like tag >> page at http://esmecloudserverapache.dickhirsch.staxapps.net/tag/Mailer >> The main snippet would just have "/" and some other snippets might >> have "../../". >> >> Then in the main javascript file, don't use any if statements. Just >> have the line: >> >> newMsg.find('#author').attr('href', relative_root_path + "user/" + >> msgAuthor.nickname ); >> >> Something along those lines. It is really ugly (global variables like >> that are a no-no and there are better ways to do it), but I think >> it'll get the job done for now. >> >> Ethan >> >
