#11 XML namespace awareness

Merged
herby merged 1 commits from Christian/xmlnsAddon into herby/master 6 months ago

Hi,

I am discovering Amber and I like it alot! Thanks! Especially, I like Silk! A very lean and concise way to code html - nice!

I want to do graphics with svg and found it difficult to handle that. So, I changed Silk to take the namespace of the instance into account. I used it for a while now and it feels nice - just like Silk.

Have a look. Maybe you like it and want to take it?

There is still the issue of creating namespaced objects out of thin air like you do with 'Silk DIV'. One idea is to have subclasses of Silk for each namespace to use, like SVG or Svg or SilkSVG. 'SVG new' would create a element and 'SVG G' would create a in its proper namespace. Another idea is to have extension methods like #svg, so you would say 'Silk svg G'. I am not decided yet. Yet this extension is already very useful (for me).

Hi, I am discovering Amber and I like it alot! Thanks! Especially, I like Silk! A very lean and concise way to code html - nice! I want to do graphics with svg and found it difficult to handle that. So, I changed Silk to take the namespace of the instance into account. I used it for a while now and it feels nice - just like Silk. Have a look. Maybe you like it and want to take it? There is still the issue of creating namespaced objects out of thin air like you do with 'Silk DIV'. One idea is to have subclasses of Silk for each namespace to use, like SVG or Svg or SilkSVG. 'SVG new' would create a <svg> element and 'SVG G' would create a <g> in its proper namespace. Another idea is to have extension methods like #svg, so you would say 'Silk svg G'. I am not decided yet. Yet this extension is already very useful (for me).
Herby Vojčík commented 6 months ago
Owner

Hi, why not? But actually, I like small additions and I presume createElement("div") and createElementNS("http://www.w3.org/1999/xhtml", "div") creates functionally (and maybe even bitwise) equivalent elements, so I think there is no need for Silk class >> htmlNamespace, Silk class >> namespace could simply return nil and the crucial code be changed to

    ^ aSilk namespace
        ifNil: [ self newElement: aString ]
        ifNotNil: [ :ns | self newElement: aString xmlns: ns ]

Also, if you agree with the above, could you please format all other returns so they have space after ^?

Also, squash / amend / rebase so it is still just one commit with smaller diff.

Hi, why not? But actually, I like small additions and I presume `createElement("div")` and `createElementNS("http://www.w3.org/1999/xhtml", "div")` creates functionally (and maybe even bitwise) equivalent elements, so I think there is no need for `Silk class >> htmlNamespace`, `Silk class >> namespace` could simply return `nil` and the crucial code be changed to ``` ^ aSilk namespace ifNil: [ self newElement: aString ] ifNotNil: [ :ns | self newElement: aString xmlns: ns ] ``` Also, if you agree with the above, could you please format all other returns so they have space after `^`? Also, squash / amend / rebase so it is still just one commit with smaller diff.
Christian Haider commented 6 months ago
Poster

Cool :-) I also think that the two create methods create identical things. I just don't know if there is a performance penalty... My thinking was more that the html create method could be dropped and only to use the namespaced method like:

newElement: aString in: aSilk
    ^ self newElement: aString xmlns: aSilk namespace

Also, squash / amend / rebase so it is still just one commit with smaller diff.

I have no idea what you are talking about :-) (I am a complete Git newbe, proud of my first pull request ever). But I'll try to find out...

Cool :-) I also think that the two create methods create identical things. I just don't know if there is a performance penalty... My thinking was more that the html create method could be dropped and only to use the namespaced method like: <pre><code>newElement: aString in: aSilk ^ self newElement: aString xmlns: aSilk namespace</code></pre> > Also, squash / amend / rebase so it is still just one commit with smaller diff. I have no idea what you are talking about :-) (I am a complete Git newbe, proud of my first pull request ever). But I'll try to find out...
Herby Vojčík commented 6 months ago
Owner

Ok. :-) Do not be afraid to try things; you can almost always reset where you started by git reset --hard commithash, and even if you lose the commithash and cannot find it in logs (eg. by rebase), there is still git reflog to find it.

What I meant that you should git commit --amend your changes, that way they are added to the last commit. And then git push -f to forcepush the mutated branch. Pull requests are bound to branch name, so if the branch is reorganized and forcepushed, it uses the new branch state (just don't get used to do git push -f in master branch; that is really a no-no).

Ok. :-) Do not be afraid to try things; you can almost always reset where you started by `git reset --hard commithash`, and even if you lose the commithash and cannot find it in logs (eg. by rebase), there is still `git reflog` to find it. What I meant that you should `git commit --amend` your changes, that way they are added to the last commit. And then `git push -f` to forcepush the mutated branch. Pull requests are bound to branch name, so if the branch is reorganized and forcepushed, it uses the new branch state (just don't get used to do `git push -f` in master branch; that is really a no-no).
Christian Haider commented 6 months ago
Poster

interesting! Thank you for the git help (that could have cost me hours with a bad result). I think it looks nice now :-)

I inlined the #newElement... method again, which makes the change clearer.

I think that this solution is ok. Now it is easy to create a Silk subclass in ones own package, like 'SVG' and just implement the class method #namespace to return the right one and everything should be fine. The 'SVG G' would create a element out of thin air - nice. What do you think?

interesting! Thank you for the git help (that could have cost me hours with a bad result). I think it looks nice now :-) I inlined the #newElement... method again, which makes the change clearer. I think that this solution is ok. Now it is easy to create a Silk subclass in ones own package, like 'SVG' and just implement the class method #namespace to return the right one and everything should be fine. The 'SVG G' would create a <g> element out of thin air - nice. What do you think?
This pull request has been merged successfully!
Sign in to join this conversation.
No Label
No Milestone
No assignee
2 Participants
Loading...
Cancel
Save
There is no content yet.