I'm working on redoing the timelines to use the same comet actors (or inherited classes) and javascript for all timelines, but I wasn't undertaking a complete rewrite of the timeline actors. 289 and 287 are more of a step towards being able to rewrite. Now that things have been refactored I think that rewrite will actually be a lot easier.
So, yes, I think a new ticket with the 5 bugs you've found as dependencies would be great and yes, I think that 1.3 is a reasonable target. Hopefully the inheritance tree of the comet actors is more or less clear, but if you have any questions as you look at it, just ask here and I'll try to tell you want I was thinking at the time. No guarantees that what I was thinking at the time actually makes any sense though ;-) Ethan On Wed, Jan 26, 2011 at 8:06 PM, ejc <[email protected]> wrote: > It appears that Ethan is already working on some of this: > > https://issues.apache.org/jira/browse/ESME-289 > and > https://issues.apache.org/jira/browse/ESME-287 > > appear related. After a quick search, I found 5 others. I plan to > create a task with these bugs as dependencies, but I'll wait for Ethan > to comment. > > Thanks, > Eric > > On Wed, Jan 26, 2011 at 10:45 AM, Richard Hirsch <[email protected]> > wrote: >> 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 >>>> >>> >> >
