DOM element ID registry at the component

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

DOM element ID registry at the component

Esteban A. Maringolo
Hi all, me again :)

Related with the previous mail about naming script builder selectors, another thing I find myself repeating over and over, is the creation, initialization and of course access of instance variables holding references to dynamically generated element id (vía `html nextId`).

Given that today's webpages, even the simples ones, use a lot of Javascript with Jquery at the client side, wouldn't it be a good addition to have a registry of these IDs at the component level? This way we would avoid creating lots of instance variables just to keep a reference to those IDs.

In some cases that reference is only needed in the context of a single method, so a temporal variable is enough, but if the code is complex and well factored you can only pass these IDs as arguments or make the temp an instance variable.

So I'm thinking about having something like:

renderSomethingOn: html
  self atId: #content put: html nextId.
  html nextIdFor: self at: #heading.
  html div
    id: (self atId: #content);
    with: [html heading id: (self atId: #heading); with: 'Foo baz'.
            "..."
       ].

WAHtmlCanvas>>#nextIdFor: aWAComponent at: aSymbol
   aWAComponent atId:aSymbol put: self nextId


These selectors aren't well thought, but the idea is that you can assign whatever you want to the registry, or you can use the canvas nextId to assing it automatically to the registry.

The registry could be lazy initialized, so components that never access it won't have an extra, empty instance of it (a GRSmallDictionary probably).

Pros:
- It would save the use of lots of instance variables
- It would "standardize" a way to access those ids other than #nextId/#lastId without requiring accessor methods for the variables.

Cons
- It would require an extra instance variable at WAComponent to reference the registry

To compensate the last one there could be a particular WAComponent subclass that has this feature, but I suspect most instances would subclass from it, so it would be the same as doing it in WAComponent directly.


What do you think?

Regards,

Esteban A. Maringolo

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: DOM element ID registry at the component

Max Leske
Hi Esteban,

I think it's a great idea. I too run into this problem a lot. I would suggest, however, to have the registry at the render loop level, not the component level. There are cases in which you may need to access the ID of an element rendered by a different component.

Cheers,
Max

On 11 September 2017 at 16:58:53, Esteban A. Maringolo ([hidden email]) wrote:

Hi all, me again :)

Related with the previous mail about naming script builder selectors, another thing I find myself repeating over and over, is the creation, initialization and of course access of instance variables holding references to dynamically generated element id (vía `html nextId`).

Given that today's webpages, even the simples ones, use a lot of Javascript with Jquery at the client side, wouldn't it be a good addition to have a registry of these IDs at the component level? This way we would avoid creating lots of instance variables just to keep a reference to those IDs.

In some cases that reference is only needed in the context of a single method, so a temporal variable is enough, but if the code is complex and well factored you can only pass these IDs as arguments or make the temp an instance variable.

So I'm thinking about having something like:

renderSomethingOn: html
  self atId: #content put: html nextId.
  html nextIdFor: self at: #heading.
  html div
    id: (self atId: #content);
    with: [html heading id: (self atId: #heading); with: 'Foo baz'.
            "..."
       ].

WAHtmlCanvas>>#nextIdFor: aWAComponent at: aSymbol
   aWAComponent atId:aSymbol put: self nextId


These selectors aren't well thought, but the idea is that you can assign whatever you want to the registry, or you can use the canvas nextId to assing it automatically to the registry.

The registry could be lazy initialized, so components that never access it won't have an extra, empty instance of it (a GRSmallDictionary probably).

Pros:
- It would save the use of lots of instance variables
- It would "standardize" a way to access those ids other than #nextId/#lastId without requiring accessor methods for the variables.

Cons
- It would require an extra instance variable at WAComponent to reference the registry

To compensate the last one there could be a particular WAComponent subclass that has this feature, but I suspect most instances would subclass from it, so it would be the same as doing it in WAComponent directly.


What do you think?

Regards,

Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: DOM element ID registry at the component

Philippe Marschall
In reply to this post by Esteban A. Maringolo
Hi

I don't think I would put that on WAComponent, WAComponent is really
generic and (in theory) doesn't even have a dependency on
WAHtmlCanvas. Also we probably don't want to backtrack it, for example
WACounter implements #states like this:

states
  ^ Array with: self

But it could definitively find a place somewhere else.

Cheers
Philippe


On Mon, Sep 11, 2017 at 4:58 PM, Esteban A. Maringolo
<[hidden email]> wrote:

> Hi all, me again :)
>
> Related with the previous mail about naming script builder selectors,
> another thing I find myself repeating over and over, is the creation,
> initialization and of course access of instance variables holding references
> to dynamically generated element id (vía `html nextId`).
>
> Given that today's webpages, even the simples ones, use a lot of Javascript
> with Jquery at the client side, wouldn't it be a good addition to have a
> registry of these IDs at the component level? This way we would avoid
> creating lots of instance variables just to keep a reference to those IDs.
>
> In some cases that reference is only needed in the context of a single
> method, so a temporal variable is enough, but if the code is complex and
> well factored you can only pass these IDs as arguments or make the temp an
> instance variable.
>
> So I'm thinking about having something like:
>
> renderSomethingOn: html
>   self atId: #content put: html nextId.
>   html nextIdFor: self at: #heading.
>   html div
>     id: (self atId: #content);
>     with: [html heading id: (self atId: #heading); with: 'Foo baz'.
>             "..."
>        ].
>
> WAHtmlCanvas>>#nextIdFor: aWAComponent at: aSymbol
>    aWAComponent atId:aSymbol put: self nextId
>
>
> These selectors aren't well thought, but the idea is that you can assign
> whatever you want to the registry, or you can use the canvas nextId to
> assing it automatically to the registry.
>
> The registry could be lazy initialized, so components that never access it
> won't have an extra, empty instance of it (a GRSmallDictionary probably).
>
> Pros:
> - It would save the use of lots of instance variables
> - It would "standardize" a way to access those ids other than
> #nextId/#lastId without requiring accessor methods for the variables.
>
> Cons
> - It would require an extra instance variable at WAComponent to reference
> the registry
>
> To compensate the last one there could be a particular WAComponent subclass
> that has this feature, but I suspect most instances would subclass from it,
> so it would be the same as doing it in WAComponent directly.
>
>
> What do you think?
>
> Regards,
>
> Esteban A. Maringolo
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: DOM element ID registry at the component

Esteban A. Maringolo
In reply to this post by Max Leske
2017-09-11 12:03 GMT-03:00 Max Leske <[hidden email]>:
>
> Hi Esteban,
>
> I think it's a great idea. I too run into this problem a lot. I would suggest, however, to have the registry at the render loop level, not the component level. There are cases in which you may need to access the ID of an element rendered by a different component.

I think that a different problem.

My problem with doing it in the render loop is that the ids are not
referenced by the component, so in my stateful world, the component
once rendered should preserve the same element ids on the client DOM,
so I want to be able to script referencing those stable ids.

Doing it on the render loop frees you from having a "one element
stack" approach that the canvas provide you with #nextId and #lastId,
but doesn't solve the original problem I stated.

Regards!

Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: DOM element ID registry at the component

Esteban A. Maringolo
In reply to this post by Philippe Marschall
2017-09-11 12:47 GMT-03:00 Philippe Marschall <[hidden email]>:
> Hi
>
> I don't think I would put that on WAComponent, WAComponent is really
> generic and (in theory) doesn't even have a dependency on
> WAHtmlCanvas. Also we probably don't want to backtrack it, for example
> WACounter implements #states like this:
>
> states
>   ^ Array with: self

I didn't think about backtracking,

Actually the #states method is something I keep forgetting about, and
hence seldom use.

> But it could definitively find a place somewhere else.

Like in my own abstract component superclass :)

Thanks!


Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: DOM element ID registry at the component

Esteban A. Maringolo
Hi all,

Coming back to this, yesterday Mariano Martinez Peck refreshed my
memory about Magritte way of dealing with this in a deterministic,
with a an acceptable collision resistance, way of generating the IDs:

MAComponent>>ajaxId: aSymbol
  ^String streamContents: [ :stream |
     stream
       nextPutAll: 'ajax';
       nextPutAll: self class name;
       print: self hash;
       nextPutAll: aSymbol ]

I don't like that it leaks the class name, but modifying the class
name with a portion of the class name hash resolves that.

So this way there is no need to keep a reference to the ID, since the
ID can be regenerated in a deterministic manner.

Regards!

Esteban A. Maringolo


2017-09-11 13:56 GMT-03:00 Esteban A. Maringolo <[hidden email]>:

> 2017-09-11 12:47 GMT-03:00 Philippe Marschall <[hidden email]>:
>> Hi
>>
>> I don't think I would put that on WAComponent, WAComponent is really
>> generic and (in theory) doesn't even have a dependency on
>> WAHtmlCanvas. Also we probably don't want to backtrack it, for example
>> WACounter implements #states like this:
>>
>> states
>>   ^ Array with: self
>
> I didn't think about backtracking,
>
> Actually the #states method is something I keep forgetting about, and
> hence seldom use.
>
>> But it could definitively find a place somewhere else.
>
> Like in my own abstract component superclass :)
>
> Thanks!
>
>
> Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev