DOM element ID registry at the component

> 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
>

> 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