[Seaside-dev] 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 (emaringolo at gmail.com)
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
seaside-dev at lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20170911/5eb3d65e/attachment.html>