SVG design questions

[Holger Kleinsorgen-3]

Hello,

after the recent discussion I've played a bit with creating SVG  on the
fly (tags, not pixels ;), and immediately stumbled on some design
questions (surprise). Because I haven't very much Seaside experience,
I'd be happy for some input/corrections/insights. Aas reward, I would be
happy to publish the stuff once it's done and desired ;)

Canvas
------
The first issue is the canvas. Subclassing the existing canvas seems to
be a bad idea:
- SVG has an extensive set of tags. Combining this with the extensive
set of HTML tags will end up in one large bulky mess
- the SVG anchor has the same tag as the HTML anchor, but requires the
xlink namespace for the href attribute, so it requires a different
anchor brush
- SVG and HTML cannot be freely mixed, so it's not necessary to combine
the both in a single class.

Currently, I've subclassed WACanvas, not WARenderCanvas. Rendering
inlined SVG will require switching the canvas. Currently I see no
problems here, but maybe I'm wrong.

Inlining
--------
Another issue is inlining SVG vs. separate SVG documents. Quite often
I've seen some caveats about inlining SVG (e.g. see
http://wiki.svg.org/Inline_SVG). On the other hand, I see some disadvantages
- not part of the DOM, contents cannot be accessed by javascript
functions of the HTML document
- rendering a separate SVG document within the context (session,
callbacks, continuations) of the Seaside component is a bit tricky

Embedding with <object>
-----------------------
I've tried to implement rendering of external SVG documents that are
included as <object> in the HTML document, and kind of succeeded:

http://www.smallish.org:7777/seaside/SVG/example

However, I'm pretty sure the hacks to make this possible will make
seasoned Seasiders vomit ;) (if someone is interested in the gory
details, I can write more about this).

I'm just a bit unsure if this effort is really necessary.

Drawing SVG in WAComponents
---------------------------
Due to the decision to use separate Canvas classes, I've introduced
separate rendering method, #drawWithContext: / #drawContentOn:, which
correspond to #renderWithContext: / #renderContentOn:.

So a component can render HTML as usual, and somewhere in the rendering
code call
    "canvas renderExternalSVG: self"
    (or #renderInlinedSVG:)

which will ultimately invoke #drawContentOn:.
#drawContentOn: receives an SVG canvas.


SomeSVGComponent>>renderContentOn: canvas
    ...
    canvas renderExternalSVG: self.
    ...

SomeSVGComponent>>drawContentOn: svg
    svg rect
       width: 100;
       height: 100;
       fill: 'rgb(220,220,220)';
       ....


_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Lukas Renggli]

Hi Holger,

Gerhard is also interested working on that. So I suggest that you
collaborate ;-)

>  The first issue is the canvas. Subclassing the existing canvas seems to be
> a bad idea:
>  - SVG has an extensive set of tags. Combining this with the extensive set
> of HTML tags will end up in one large bulky mess
>  - the SVG anchor has the same tag as the HTML anchor, but requires the
> xlink namespace for the href attribute, so it requires a different anchor
> brush
>  - SVG and HTML cannot be freely mixed, so it's not necessary to combine the
> both in a single class.

I suggest that you create your own "namespace" that you can retrieve
from the html canvas. This would be an object that knows the
underlying rendering context, but only has the SVG relevant methods.

So that you can write:

   html svg line
      from: 1 @ 1;
      to: 100 @ 100

Or for embedded SVG rendering I imagine writing something like:

    html svg: [ html renderSvgOn: html svg ]

Where renderSvgOn: would look like:

    renderSvgOn: svg
       svg line
          from: 1 @ 1;
          to: 100 @ 100

>  Currently, I've subclassed WACanvas, not WARenderCanvas. Rendering inlined
> SVG will require switching the canvas. Currently I see no problems here, but
> maybe I'm wrong.

I think that's the way to go.

>  Another issue is inlining SVG vs. separate SVG documents. Quite often I've
> seen some caveats about inlining SVG (e.g. see
> http://wiki.svg.org/Inline_SVG). On the other hand, I see some disadvantages

I have no experience with that.

I think inlining seems simpler to start with. Have a look at the
#iframe brush to see how to create a specific document as part of the
page.

>  Embedding with <object>
>  -----------------------
>  I've tried to implement rendering of external SVG documents that are
> included as <object> in the HTML document, and kind of succeeded:
>
>  http://www.smallish.org:7777/seaside/SVG/example

Wow, that looks already very cool.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Gerhard Obermann]

Hi!

 

It looks very cool, so please create a squeak package on squeaksource and assign me as developer!

 

AFAIK Inline SVG hast too many drawbacks (especially on IE), so the main goal should be the rendering for linked SVG documents.

 

BTW: Which version are you using!

I think it should be developed for Seaside 2.9!

 

br

 

Gerhard

 

 

On 4/9/08, Lukas Renggli <renggli@...> wrote:

Hi Holger,

Gerhard is also interested working on that. So I suggest that you
collaborate ;-)

>  The first issue is the canvas. Subclassing the existing canvas seems to be
> a bad idea:
>  - SVG has an extensive set of tags. Combining this with the extensive set
> of HTML tags will end up in one large bulky mess
>  - the SVG anchor has the same tag as the HTML anchor, but requires the
> xlink namespace for the href attribute, so it requires a different anchor
> brush
>  - SVG and HTML cannot be freely mixed, so it's not necessary to combine the
> both in a single class.

I suggest that you create your own "namespace" that you can retrieve
from the html canvas. This would be an object that knows the
underlying rendering context, but only has the SVG relevant methods.

So that you can write:

  html svg line
     from: 1 @ 1;
     to: 100 @ 100

Or for embedded SVG rendering I imagine writing something like:

   html svg: [ html renderSvgOn: html svg ]

Where renderSvgOn: would look like:

   renderSvgOn: svg
      svg line
         from: 1 @ 1;
         to: 100 @ 100

>  Currently, I've subclassed WACanvas, not WARenderCanvas. Rendering inlined
> SVG will require switching the canvas. Currently I see no problems here, but
> maybe I'm wrong.

I think that's the way to go.

>  Another issue is inlining SVG vs. separate SVG documents. Quite often I've
> seen some caveats about inlining SVG (e.g. see
> http://wiki.svg.org/Inline_SVG). On the other hand, I see some disadvantages

I have no experience with that.

I think inlining seems simpler to start with. Have a look at the
#iframe brush to see how to create a specific document as part of the
page.

>  Embedding with <object>
>  -----------------------
>  I've tried to implement rendering of external SVG documents that are
> included as <object> in the HTML document, and kind of succeeded:
>
>  http://www.smallish.org:7777/seaside/SVG/example

Wow, that looks already very cool.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Marcin Tustin]

I'd be interested in having a play with the code as well. It looks like this is all your own hand-rolled stuff, right?

On Wed, Apr 9, 2008 at 11:22 AM, Gerhard Obermann <obi068@...> wrote:

Hi!

 

It looks very cool, so please create a squeak package on squeaksource and assign me as developer!

 

AFAIK Inline SVG hast too many drawbacks (especially on IE), so the main goal should be the rendering for linked SVG documents.

 

BTW: Which version are you using!

I think it should be developed for Seaside 2.9!

 

br

 

Gerhard

 

 

On 4/9/08, Lukas Renggli <renggli@...> wrote:

Hi Holger,

Gerhard is also interested working on that. So I suggest that you
collaborate ;-)

>  The first issue is the canvas. Subclassing the existing canvas seems to be
> a bad idea:
>  - SVG has an extensive set of tags. Combining this with the extensive set
> of HTML tags will end up in one large bulky mess
>  - the SVG anchor has the same tag as the HTML anchor, but requires the
> xlink namespace for the href attribute, so it requires a different anchor
> brush
>  - SVG and HTML cannot be freely mixed, so it's not necessary to combine the
> both in a single class.

I suggest that you create your own "namespace" that you can retrieve
from the html canvas. This would be an object that knows the
underlying rendering context, but only has the SVG relevant methods.

So that you can write:

  html svg line
     from: 1 @ 1;
     to: 100 @ 100

Or for embedded SVG rendering I imagine writing something like:

   html svg: [ html renderSvgOn: html svg ]

Where renderSvgOn: would look like:

   renderSvgOn: svg
      svg line
         from: 1 @ 1;
         to: 100 @ 100

>  Currently, I've subclassed WACanvas, not WARenderCanvas. Rendering inlined
> SVG will require switching the canvas. Currently I see no problems here, but
> maybe I'm wrong.

I think that's the way to go.

>  Another issue is inlining SVG vs. separate SVG documents. Quite often I've
> seen some caveats about inlining SVG (e.g. see
> http://wiki.svg.org/Inline_SVG). On the other hand, I see some disadvantages

I have no experience with that.

I think inlining seems simpler to start with. Have a look at the
#iframe brush to see how to create a specific document as part of the
page.

>  Embedding with <object>
>  -----------------------
>  I've tried to implement rendering of external SVG documents that are
> included as <object> in the HTML document, and kind of succeeded:
>
>  http://www.smallish.org:7777/seaside/SVG/example

Wow, that looks already very cool.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Sebastian Sastre-2]

This encourage the initiative:

http://www.digital-web.com/articles/svg_the_new_flash/

http://operawatch.com/news/2008/03/is-apple-looking-to-svg-as-a-flash-replacemen
t-for-the-iphone.html

        cheers
 
Sebastian Sastre

 

 


________________________________

        De: seaside-bounces@...
[mailto:seaside-bounces@...] En nombre de Gerhard
Obermann
        Enviado el: Miércoles, 09 de Abril de 2008 07:22
        Para: Seaside - general discussion
        Asunto: Re: [Seaside] SVG design questions
       
       
        Hi!
         
        It looks very cool, so please create a squeak package on squeaksource
and assign me as developer!
         
        AFAIK Inline SVG hast too many drawbacks (especially on IE), so the main
goal should be the rendering for linked SVG documents.
         
        BTW: Which version are you using!
        I think it should be developed for Seaside 2.9!
         
        br
         
        Gerhard
         


         
        On 4/9/08, Lukas Renggli <renggli@...> wrote:

                Hi Holger,
               
                Gerhard is also interested working on that. So I suggest that
you
                collaborate ;-)
               
                >  The first issue is the canvas. Subclassing the existing
canvas seems to be
                > a bad idea:
                >  - SVG has an extensive set of tags. Combining this with the
extensive set
                > of HTML tags will end up in one large bulky mess
                >  - the SVG anchor has the same tag as the HTML anchor, but
requires the
                > xlink namespace for the href attribute, so it requires a
different anchor
                > brush
                >  - SVG and HTML cannot be freely mixed, so it's not necessary
to combine the
                > both in a single class.
               
                I suggest that you create your own "namespace" that you can
retrieve
                from the html canvas. This would be an object that knows the
                underlying rendering context, but only has the SVG relevant
methods.
               
                So that you can write:
               
                  html svg line
                     from: 1 @ 1;
                     to: 100 @ 100
               
                Or for embedded SVG rendering I imagine writing something like:
               
                   html svg: [ html renderSvgOn: html svg ]
               
                Where renderSvgOn: would look like:
               
                   renderSvgOn: svg
                      svg line
                         from: 1 @ 1;
                         to: 100 @ 100
               
                >  Currently, I've subclassed WACanvas, not WARenderCanvas.
Rendering inlined
                > SVG will require switching the canvas. Currently I see no
problems here, but
                > maybe I'm wrong.
               
                I think that's the way to go.
               
                >  Another issue is inlining SVG vs. separate SVG documents.
Quite often I've
                > seen some caveats about inlining SVG (e.g. see
                > http://wiki.svg.org/Inline_SVG). On the other hand, I see some
disadvantages
               
                I have no experience with that.
               
                I think inlining seems simpler to start with. Have a look at the
                #iframe brush to see how to create a specific document as part
of the
                page.
               
                >  Embedding with <object>
                >  -----------------------
                >  I've tried to implement rendering of external SVG documents
that are
                > included as <object> in the HTML document, and kind of
succeeded:
                >
                >  http://www.smallish.org:7777/seaside/SVG/example
               
                Wow, that looks already very cool.
               
                Cheers,
                Lukas
               
                --
                Lukas Renggli
                http://www.lukas-renggli.ch
                _______________________________________________
                seaside mailing list
                seaside@...
       
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
               



_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Holger Kleinsorgen-3]

Hello,

 > It looks very cool, so please create a squeak package on squeaksource and
 > assign me as developer!

I'll try to. However, my Squeak experience is restricted to a few
minutes of clicking through examples. Usually I'm using VisualWorks.

 > AFAIK Inline SVG hast too many drawbacks (especially on IE), so the main
 > goal should be the rendering for linked SVG documents.

Although browser compatibility is a serious issue, I favor the "inlined
SVG first" approach. Besides the DOM/Javascript and Context problems
I've mentioned, the future of Adobe's SVG viewer doesn't look very bright:

"Adobe has decided to discontinue support for Adobe SVG Viewer. There
are a number of other third-party SVG viewer implementations in the
marketplace, including native support for SVG in many Web browsers. The
SVG language and its adoption in the marketplace have both matured to
the point where it is no longer necessary for Adobe to provide an SVG
viewer"

(from http://www.adobe.com/svg/eol.html)

Supporting both methods would be ideal, of course.

 > BTW: Which version are you using!
 > I think it should be developed for Seaside 2.9!

Seaside 2.8. Supporting 2.9 shouldn't be a major problem (unless there's
a secret plan to dump canvases and brushes ;)

> I'd be interested in having a play with the code as well. It looks like this
> is all your own hand-rolled stuff, right?

A home-grown bunch of wacky code, yes. With only three brushes. Have to
clean it up a bit, and somehow manage to get used to Squeak. But I've
got some spare time, so I hope to relase some stuff soon.


_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Gerhard Obermann]

Some parts of this message have been removed. Learn more about Nabble's security policy.

You could also send me the vw fileout (not xml please) and

i could do the squeak port and the package on squeaksource!

 

br

Gerhard

 

On 4/9/08, Holger Kleinsorgen <kleinsor@...> wrote:

Hello,

> It looks very cool, so please create a squeak package on squeaksource and
> assign me as developer!

I'll try to. However, my Squeak experience is restricted to a few minutes of clicking through examples. Usually I'm using VisualWorks.

> AFAIK Inline SVG hast too many drawbacks (especially on IE), so the main
> goal should be the rendering for linked SVG documents.

Although browser compatibility is a serious issue, I favor the "inlined SVG first" approach. Besides the DOM/Javascript and Context problems I've mentioned, the future of Adobe's SVG viewer doesn't look very bright:

"Adobe has decided to discontinue support for Adobe SVG Viewer. There are a number of other third-party SVG viewer implementations in the marketplace, including native support for SVG in many Web browsers. The SVG language and its adoption in the marketplace have both matured to the point where it is no longer necessary for Adobe to provide an SVG viewer"

(from http://www.adobe.com/svg/eol.html)

Supporting both methods would be ideal, of course.

> BTW: Which version are you using!
> I think it should be developed for Seaside 2.9!

Seaside 2.8. Supporting 2.9 shouldn't be a major problem (unless there's a secret plan to dump canvases and brushes ;)

I'd be interested in having a play with the code as well. It looks like this
is all your own hand-rolled stuff, right?

A home-grown bunch of wacky code, yes. With only three brushes. Have to clean it up a bit, and somehow manage to get used to Squeak. But I've got some spare time, so I hope to relase some stuff soon.

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Marcin Tustin]

If the fileout is even remotely compatible with squeak, I'd be very happy to receive that as well.

On Wed, Apr 9, 2008 at 4:27 PM, Gerhard Obermann <obi068@...> wrote:

You could also send me the vw fileout (not xml please) and

i could do the squeak port and the package on squeaksource!

 

br

Gerhard

 

On 4/9/08, Holger Kleinsorgen <kleinsor@...> wrote:

Hello,

> It looks very cool, so please create a squeak package on squeaksource and
> assign me as developer!

I'll try to. However, my Squeak experience is restricted to a few minutes of clicking through examples. Usually I'm using VisualWorks.

> AFAIK Inline SVG hast too many drawbacks (especially on IE), so the main
> goal should be the rendering for linked SVG documents.

Although browser compatibility is a serious issue, I favor the "inlined SVG first" approach. Besides the DOM/Javascript and Context problems I've mentioned, the future of Adobe's SVG viewer doesn't look very bright:

"Adobe has decided to discontinue support for Adobe SVG Viewer. There are a number of other third-party SVG viewer implementations in the marketplace, including native support for SVG in many Web browsers. The SVG language and its adoption in the marketplace have both matured to the point where it is no longer necessary for Adobe to provide an SVG viewer"

(from http://www.adobe.com/svg/eol.html)

Supporting both methods would be ideal, of course.

> BTW: Which version are you using!
> I think it should be developed for Seaside 2.9!

Seaside 2.8. Supporting 2.9 shouldn't be a major problem (unless there's a secret plan to dump canvases and brushes ;)

I'd be interested in having a play with the code as well. It looks like this
is all your own hand-rolled stuff, right?

A home-grown bunch of wacky code, yes. With only three brushes. Have to clean it up a bit, and somehow manage to get used to Squeak. But I've got some spare time, so I hope to relase some stuff soon.

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Holger Kleinsorgen-3]

Marcin Tustin schrieb:
> If the fileout is even remotely compatible with squeak, I'd be very happy to
> receive that as well.
>
> On Wed, Apr 9, 2008 at 4:27 PM, Gerhard Obermann <obi068@...> wrote:
>
>> You could also send me the vw fileout (not xml please) and
>> i could do the squeak port and the package on squeaksource!

done... Project name is "SeasideDynamicSVG" (I hope this is ok)

http://www.squeaksource.com/SeasideDynamicSVG.html

if someone wants to be added as developer, please yell
(Gerhard: already added as admin)

cheers, Holger
_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Gerhard Obermann]

Well its working (also for IE7 !),

but currently we have too many hacks.

 

Main issues:

- I didnt get IE7 working without using the embed tag.

- The "embed" tag is not a W3C standard!

- Its not a good solution to use the same continuation for the html rendering and

the embeded svg.

 

I dont want to continue if the main issues are not solved!

 

Ill hope one of the core developers could give us some hints to

avoid some of the hacks.

 

BTW: We should continue on seaside-dev !

 

br

Gerhard

 

 

 

On Wed, Apr 9, 2008 at 7:43 PM, Holger Kleinsorgen <kleinsor@...> wrote:

Marcin Tustin schrieb:

If the fileout is even remotely compatible with squeak, I'd be very happy to
receive that as well.

On Wed, Apr 9, 2008 at 4:27 PM, Gerhard Obermann <obi068@...> wrote:

You could also send me the vw fileout (not xml please) and
i could do the squeak port and the package on squeaksource!

done... Project name is "SeasideDynamicSVG" (I hope this is ok)

http://www.squeaksource.com/SeasideDynamicSVG.html

if someone wants to be added as developer, please yell
(Gerhard: already added as admin)

cheers, Holger

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Holger Kleinsorgen-3]

Hello,
> Well its working (also for IE7 !),
> but currently we have too many hacks.
>
> Main issues:
> - I didnt get IE7 working without using the embed tag.
> - The "embed" tag is not a W3C standard!
>  
we can blame Microsoft and/or Adobe, but Seaside cannot magically solve
browser issues.
Did you follow the hints on this page?
http://www.s-v-g.net/faqSVGumfeld.php

on the other hand:
"The URL is required to determine the security zone, which is required
to determine the state of the ActiveScripting setting. Therefore, to
fail safe against this potential security flaw Adobe SVG Viewer 3.01
always disables scripting when it determines that the SVG file is
embedded using the OBJECT tag. When authoring in SVG, Adobe recommends
that you not use the OBJECT tag and instead use the EMBED tag when
embedding SVG in HTML pages."

(http://www.adobe.com/svg/viewer/install/main.html)

and Microsoft obviously wants to push WVG sooner or later. Trying to get
it work 100% W3 conformant in a browser that is notorius for
non-conformance is maybe too ambitious.
> - Its not a good solution to use the same continuation for the html
> rendering and
> the embeded svg.
>  
I disagree, on two levels
- there are two continuations, a SVGHybridRenderContinuation (for
rendering the HTML), and a SVGRenderContination (for rendering the SVG)
- actually I'd like to have only one continuation. For me, the SVG image
is more or less like a component, and shouldnt require  a separate
contiuation

another reason that favors inlined SVG...
> I dont want to continue if the main issues are not solved!
>  
that would be a pity! I'm pretty sure we can get it work in IE, too.

_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Philippe Marschall]

2008/4/9, Holger Kleinsorgen <kleinsor@...>:

> Hello,
>
>  after the recent discussion I've played a bit with creating SVG  on the fly
> (tags, not pixels ;), and immediately stumbled on some design questions
> (surprise). Because I haven't very much Seaside experience, I'd be happy for
> some input/corrections/insights. Aas reward, I would be happy to publish the
> stuff once it's done and desired ;)
>
>  Canvas
>  ------
>  The first issue is the canvas. Subclassing the existing canvas seems to be
> a bad idea:
>  - SVG has an extensive set of tags. Combining this with the extensive set
> of HTML tags will end up in one large bulky mess
>  - the SVG anchor has the same tag as the HTML anchor, but requires the
> xlink namespace for the href attribute, so it requires a different anchor
> brush
>  - SVG and HTML cannot be freely mixed, so it's not necessary to combine the
> both in a single class.
>
>  Currently, I've subclassed WACanvas, not WARenderCanvas. Rendering inlined
> SVG will require switching the canvas. Currently I see no problems here, but
> maybe I'm wrong.
>
>  Inlining
>  --------
>  Another issue is inlining SVG vs. separate SVG documents. Quite often I've
> seen some caveats about inlining SVG (e.g. see
> http://wiki.svg.org/Inline_SVG). On the other hand, I see some disadvantages
>  - not part of the DOM, contents cannot be accessed by javascript functions
> of the HTML document
>  - rendering a separate SVG document within the context (session, callbacks,
> continuations) of the Seaside component is a bit tricky
>
>  Embedding with <object>
>  -----------------------
>  I've tried to implement rendering of external SVG documents that are
> included as <object> in the HTML document, and kind of succeeded:
>
>  http://www.smallish.org:7777/seaside/SVG/example
>
>  However, I'm pretty sure the hacks to make this possible will make seasoned
> Seasiders vomit ;) (if someone is interested in the gory details, I can
> write more about this).
>
>  I'm just a bit unsure if this effort is really necessary.
>
>  Drawing SVG in WAComponents
>  ---------------------------
>  Due to the decision to use separate Canvas classes, I've introduced
> separate rendering method, #drawWithContext: / #drawContentOn:, which
> correspond to #renderWithContext: / #renderContentOn:.
>
>  So a component can render HTML as usual, and somewhere in the rendering
> code call
>    "canvas renderExternalSVG: self"
>    (or #renderInlinedSVG:)
>
>  which will ultimately invoke #drawContentOn:.
>  #drawContentOn: receives an SVG canvas.
>
>
>  SomeSVGComponent>>renderContentOn: canvas
>    ...
>    canvas renderExternalSVG: self.
>    ...
>
>  SomeSVGComponent>>drawContentOn: svg
>    svg rect
>       width: 100;
>       height: 100;
>       fill: 'rgb(220,220,220)';
>       ....

Just a side note here. Wherever possible we tried to avoid the C-ish
names of html elements in Seaside and used full names instead. So
instead of #img we name #image. Here this would mean #rectangle
instead of #rect.

Cheers
Philippe
_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Steve Aldred-3]

In the "SVG design questions" thread Philippe Marschall wrote:
> Just a side note here. Wherever possible we tried to avoid the C-ish
> names of html elements in Seaside and used full names instead. So
> instead of #img we name #image. Here this would mean #rectangle
> instead of #rect.
>  

Not trying to be difficult or anything but why?

Given to use Seaside you have to have a good understanding of HTML where
is the advantage in translating tags to different message name? Renaming
for the sake of being 'Smalltalkish" just makes entry for existing web
developers that much more difficult. How many people have tried to send
#tr and #td?

When it comes to debugging on the client you have to read the HTML
anyway, I just don't see the benefit of having another name for most tags.

If the same Seaside code could be used to render something other than
HTML then fair enough, is there someone doing that or is it very likely?

OTOH if things are going to be renamed then everything should be,
including attributes (e.g. colSpan) and the rest of the elements e.g. div.

Just my 2c.

cheers
Steve



_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[Edward Stow]

On Fri, Apr 11, 2008 at 11:18 AM, Steve Aldred
<aldreds@...> wrote:

> In the "SVG design questions" thread Philippe Marschall wrote:
>
> > Just a side note here. Wherever possible we tried to avoid the C-ish
> > names of html elements in Seaside and used full names instead. So
> > instead of #img we name #image. Here this would mean #rectangle
> > instead of #rect.
> >
> >
>
>  Not trying to be difficult or anything but why?
>
>  Given to use Seaside you have to have a good understanding of HTML where is
> the advantage in translating tags to different message name? Renaming for
> the sake of being 'Smalltalkish" just makes entry for existing web
> developers that much more difficult. How many people have tried to send #tr
> and #td?

+ 1  I would prefer to use html tag names, td, tr, a.

And seaside adds to the html language disconnect by using #url: for
src and href attributes.

--

Edward Stow
_______________________________________________
seaside mailing list
seaside@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside