SVG design questions
Locked
12
12
 
|
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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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 <[hidden email]> wrote:
Hi Holger, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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 <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Gerhard Obermann
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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> 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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: SVG design questions
|
|
In reply to this post by Marcin Tustin
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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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 <[hidden email]> wrote:
Hello, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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 <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: SVG design questions
|
|
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 <[hidden email]> 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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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 <[hidden email]> wrote: Marcin Tustin schrieb: _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: SVG design questions
|
|
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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Holger Kleinsorgen-3
2008/4/9, Holger Kleinsorgen <[hidden email]>:
> 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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
HTML method naming conventions
|
|
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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: HTML method naming conventions
|
|
On Fri, Apr 11, 2008 at 11:18 AM, Steve Aldred
<[hidden email]> 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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: HTML method naming conventions
|
|
On 10-Apr-08, at 7:44 PM, Edward Stow wrote: > + 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. - 1 The most important consideration is readability. That's better served by fidelity to Smalltalk conventions than by fidelity to the HTML spec. A rendering method is Smalltalk code that generates HTML, not a template language. That's a good thing - rendering code can be refactored like any other Smalltalk code, and can thus generate complex interfaces that would be difficult or impossible with something that had more fidelity to HTML. Colin _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: HTML method naming conventions
|
|
In reply to this post by Edward Stow
On Thu, Apr 10, 2008 at 7:44 PM, Edward Stow <[hidden email]> wrote:
> + 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. There's a tradeoff here between consistency with the HTML language and internal consistency of the API. I lean towards internal consistency: for example, it's bizarre that an HTML textarea is so different from an HTML text input. *Why* are "src" and "href" different attributes when they are both URLs? In both of these cases, Seaside unifies the two cases even though HTML does not. For that matter, Seaside presents links and submit buttons nearly identically, even though in HTML/HTTP they are entirely different mechanisms. I think this abstraction and unification is a good thing. If you want an API that precisely models HTML and HTTP, you're using the wrong framework - there are many others (the vast majority) that do so. Cheers, Avi _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: HTML method naming conventions
|
|
In reply to this post by Steve Aldred-3
I agree with Colin, we have abstracted html into a more readable and elegant Smalltalk syntax and it works great once you get into it, look for long term benefits, not immediate 1-to-1 comparisons. Having that said, there's no reason why someone couldn't just make a package of html-like accessors if they felt strongly about it, but then you are moving away from what the rest of the Seaside world had settled on. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: HTML method naming conventions
|
|
In reply to this post by Edward Stow
Edward Stow wrote:
> On Fri, Apr 11, 2008 at 11:18 AM, Steve Aldred > <[hidden email]> 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. There's a SVG example that lets me agree with the "full names" policy: The SVG path tag. The following example draws a simple pie chart: <path d="M600,350 l 50,-25 a25,25 -30 0,1 50,-25 l 50,-25 a25,50 -30 0,1 50,-25 l 50,-25 a25,75 -30 0,1 50,-25 l 50,-25 a25,100 -30 0,1 50,-25 l 50,-25" fill="none" stroke="red" stroke-width="5"/> the path is encoded in the "d" attribute as a set of primitives. A letter represends a command (move to, elliptical arc to). Uppercase characters imply absolute coordinates, lowercase characters relative coordinates. If this would be translated directly into a SVGPathTag, using the names specified in the W3C SVG spec, the Smalltalk code would look like this: svg path d: "M600,350 l 50,-25 a25,25 -30 0,1 50,-25 l 50,-25 a25,50 -30 0,1 50,-25 l 50,-25 a25,75 -30 0,1 50,-25 l 50,-25 a25,100 -30 0,1 50,-25 l 50,-25" or svg path Mx: 600 y: 350; lx: 50 y: -25; arx: 25 ry: 25 x-axis-rotation: -30 large-arc-flag: 0 sweep-flag: 1 x: 50 y: 25; lx: 50 y: -25; .... or maybe svg path M: 600@350; l: 50@-25; a: 25@25 x-axis-rotation: -30 large-arc-flag: 0 sweep-flag: 1 to: 50@25; lx: 50 y: -25; .... but currently it looks like this: svg path moveTo: 600@350 relative: false; lineTo: 50@-25 relative: true; arcTo: 50@25 radius: 25@25 rotation: -30 large: true sweep: true relative: true. lineTo: 50@25 relative: true; ... or alternatively (using a state flag) svg path moveTo: 600@350 relative: false; defaultIsRelative; lineTo: 50@-25; arcTo: 50@25 radius: 25@25 rotation: -30 large: true sweep: true; lineTo: 50@25; ... much easier to read. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: HTML method naming conventions
|
|
On Fri, Apr 11, 2008 at 6:23 PM, Holger Kleinsorgen
<[hidden email]> wrote: > > Edward Stow wrote: > > > On Fri, Apr 11, 2008 at 11:18 AM, Steve Aldred > > <[hidden email]> 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. > > > > > There's a SVG example that lets me agree with the "full names" policy: > ... > > much easier to read. In effect the seaside html rendering and the svg rendering examples are a DSL but one that cannot be understood by itself. I have to agree that the code is neater .. but .. in both the html or svg rendering my bet is that you 'debug' your documents by examining the html / svg produced. And that you work out what html/svg element / attribute you need to add or change for the desired effect and then write the corresponding smalltalk rendering code. So in effect you are working in both the html / svg and the domain specific languages. But this issue is really small beer in relation to the advantages of Seaside. -- Edward Stow _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: HTML method naming conventions
|
|
In reply to this post by Edward Stow
> > 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. -1 Abbreviations are evil, Smalltalk convention is to use actual readable words for method names. Seaside does exactly the right thing preferring things like anchor, tableData, and tableRow. Code should be able to be read aloud, and when spoken aloud, we say anchor, not "a". Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |