[Edbrowse-dev] Dynamic Menus

[Edbrowse-dev] Dynamic Menus

[Karl Dahlke]

Yes, they work now!
It's not intrusive; if they give you any trouble at all then just
comment out the call to rebuildSelectors() in html.cpp.

Bring up jsrt, select a state,
and You get two different sets of colors to choose from below,
depending on whether the state is A through M or N through Z.
This is how a lot of real world sites work.

Fun? Sure it was fun, always fun to program new and interesting features.

Expedient? Without doubt. I'm Trying to support more websites.

Forward looking? Well maybe. Just a little.
My tags continue to be the representation of the page, js independent,
and then the render selector function is part of a post scan,
to see which js objects have changed,
and map those changes back to the html tags, and report same to user.
Maybe it's a prototype for where we want to go.

Oh by the way, scanning the tree of js objects with a 100% js function,
and doc writing the output in some ascii string,
and converting that back into tags,
that nifty idea is dead on arrival.
Writing a prototype is a great way to see what works and what doesn't.
It doesn't work because I don't have a good way to embed pointers to the
js objects in the ascii output stream.
Oh maybe a way %p but not a good way,
and I need each html tag to point (t->jv) to its corresponding js object.
And there are other ways that it doesn't work so well, as Adam has noted.

My first post-scan function isn't really too bad.
It plods along, but none of the code is hard to follow.
See rebuildSelector and rebuildSelectors in jsloc.cpp.
If you have a moment, look at these and we can think about how
it might scale up to a more general post-scan of any changes on the page.
Also the newSelect() function in jsrt.
Meantime it's a little code that helps a lot.
It's kind of cool to pick the state and have new colors appear
in the submenu below.

One more observation, with jspool = 2, smallest it can be, I ran into a site
wherein things stopped working properly,
but they worked fine with a larger jsppool.
So I think sometimes we run into memory errors that aren't reported to us,
and so we don't shut down js as we should.
Adam mentioned this in a recursive situation.
So sm js continues to hold mysteries.

Karl Dahlke

Re: [Edbrowse-dev] Dynamic Menus

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

On Thu, Mar 13, 2014 at 10:43:45AM -0400, Karl Dahlke wrote:
> Yes, they work now!
> It's not intrusive; if they give you any trouble at all then just
> comment out the call to rebuildSelectors() in html.cpp.
Well done for getting this working.
> Bring up jsrt, select a state,
> and You get two different sets of colors to choose from below,
> depending on whether the state is A through M or N through Z.
> This is how a lot of real world sites work.

Yeah, all works as expected on my machine.

> Fun? Sure it was fun, always fun to program new and interesting features.

Agreed.

> Expedient? Without doubt. I'm Trying to support more websites.

Yep, and this got in before the release which is a good thing.

> Forward looking? Well maybe. Just a little.
> My tags continue to be the representation of the page, js independent,
> and then the render selector function is part of a post scan,
> to see which js objects have changed,
> and map those changes back to the html tags, and report same to user.
> Maybe it's a prototype for where we want to go.

Yeah perhaps.

> Oh by the way, scanning the tree of js objects with a 100% js function,
> and doc writing the output in some ascii string,
> and converting that back into tags,
> that nifty idea is dead on arrival.
> Writing a prototype is a great way to see what works and what doesn't.
> It doesn't work because I don't have a good way to embed pointers to the
> js objects in the ascii output stream.
> Oh maybe a way %p but not a good way,
> and I need each html tag to point (t->jv) to its corresponding js object.
> And there are other ways that it doesn't work so well, as Adam has noted.

I hadn't thought of the pointer thing,
as you say prototyping is always a good idea.

> My first post-scan function isn't really too bad.
> It plods along, but none of the code is hard to follow.
> See rebuildSelector and rebuildSelectors in jsloc.cpp.

When I've got a bit more time I'll do this.

> If you have a moment, look at these and we can think about how
> it might scale up to a more general post-scan of any changes on the page.
> Also the newSelect() function in jsrt.

Yes, sounds interesting. Unfortunately my spare time is somewhat limited at the
moment, so I doubt I'll be able to seriously look through the code for at least a week.

> Meantime it's a little code that helps a lot.
> It's kind of cool to pick the state and have new colors appear
> in the submenu below.
Agreed, and it seems to run quickly as well.

> One more observation, with jspool = 2, smallest it can be, I ran into a site
> wherein things stopped working properly,
> but they worked fine with a larger jsppool.
> So I think sometimes we run into memory errors that aren't reported to us,
> and so we don't shut down js as we should.
Yeah.

> Adam mentioned this in a recursive situation.
> So sm js continues to hold mysteries.
I think the recursive situation is slightly different since I ran with jspool=8
and jspool=128 and got the same limit,
so it looks like smjs has some other setting controlling internal stack size
(or maybe just a recursion limit somewhere).
It'd be cool if we could alter this as well.
Also, once it stopped recursing, I could re-run the function again without
doing anything to js.

Would it be useful if I put a "Recurse" button in jsrt?

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]