Enhance position option with :append and :prepend options to inject code at start or end of head or body tags#36
Enhance position option with :append and :prepend options to inject code at start or end of head or body tags#36salimhb wants to merge 7 commits into
Conversation
…ng of the :position tag
There was a problem hiding this comment.
hm... I mean it's not critical but I don't really like the semantics here. With your change position is not precise anymore. Maybe we should call it container or something, and let the position be opening/closing ?
There was a problem hiding this comment.
Yeah. I wasn't sure about the semantics here either. But I wanted to just get this PR out to get feedback about this.
:container/:position actually sound better. Thanks :)
There was a problem hiding this comment.
done now with container_tag and container_position. I avoided changing the position attribute at first to avoid changing it everywhere.
|
I find the the wording with |
|
👍 for prepend/append |
|
That also sounds good. Getting more inspired by jquery, I was also thinking of using |
There was a problem hiding this comment.
I mean, yes it's a first draft. But what I totally dislike about this code is the responsibility of the tracker.
It was not optimal before, but now it's even worse. Why do the tracker need to ask the handler about his position, to again decide which "message" to send to it again.... weird. The handler should take care of all that.
There was a problem hiding this comment.
this inject method gets the response, changes it, and returns it.
If we want to move this inject into the handlers, then we would need to pass the response again to an inject method inside each handler. Doesn't that make it slower and more difficult to understand what is happening? It would also allow the handler to change whatever else it likes in the response!
Another way I could think of doing this is to group handlers according to their container_tag and container_position, render them together, and then gsub once for each group. What do you think about that?
There was a problem hiding this comment.
I'm with you on the response.gsub part,... but I think the behavior what comes first/last (the position) should be inside of the handler.
btw. </#{handler.container_tag}> doesn't match elements with attributes right?
There was a problem hiding this comment.
Then what do you think about the grouping idea?
And yeah, good catch, that affects the code 2 lines below! I'll change it and add a spec for that.
There was a problem hiding this comment.
a17b6c0 should take care of the element with attributes issue
|
hm position_inside/position_insert sounds weird too imho. why not give it a method and let it look more like a DSL? |
|
I discarded the idea of using a hash at the beginning, but this way it looks actually nice. |
|
i like @DonSchado idea, we might even go further and get rid of
or
also there are already some issues with the naive regex approach, we should not drive further into this direction and opening new potential problems |
|
salim pls also consider to address this issue here: #28 gsub is bad! ;) |
|
#28 can be resolved if we first render the handlers for a certain position together, then inject them in one step. |
|
in which state is this now? do you need any help on this? or feedback on a specific problem? |
|
This is done with the following format now: or Of course, it has to be updated with the latest master. |
|
first of all, I'm cool with the use case, but to be honest I'm not fully satisfied with this solution. |
|
let's do that 💚 |
|
😴 ;) |
|
I would like to fix this up, so it can be merged. What exactly would need to be done differently? Are we OK with the positioning syntax? |
|
closing this PR in favor of #84 That PR allows handers to define a |
No description provided.