Hi,
I use WABuilder for creating small chunks of html-Code to test the SVGTags. Unfortunately it is not possible to pass a RenderContext into WABuilder>>render: WABuilder>>render: anObject ^ String streamContents: [ :stream | | context document renderer | ... context := WARenderContext new. ... renderer := self rendererClass context: context. self openDocument: document context: context. renderer render: anObject; flush. self closeDocument: document ] so I would like to change the method and split it up in two methods: WABuilder>>render: ^ self render: anObject withContext: WARenderContext new. and WABuilder>>render:withContext: WABuilder>>render: anObject ^ String streamContents: [ :stream | | context document renderer | ... context := aWARenderContext. ... renderer := self rendererClass context: context. self openDocument: document context: context. renderer render: anObject; flush. self closeDocument: document ] Is that OK and conforming to your development rules? How do I proceed if it is ok to implement? Regards Max _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
I don't know about SVG documents. But what I do to generate small
chunks of HTML content is: WAHtmlCanvas builder render: [ :html | html text: 'Hello world' ] So maybe you should have your own WASvgCanvas and maybe a WASvgDocument too. Regards! Esteban A. Maringolo 2014-08-25 13:16 GMT-03:00 Maximilian Bareis <[hidden email]>: > Hi, > > I use WABuilder for creating small chunks of html-Code to test the SVGTags. > Unfortunately it is not possible to pass a RenderContext into > WABuilder>>render: > > WABuilder>>render: anObject > ^ String streamContents: [ :stream | > | context document renderer | > ... > context := WARenderContext new. > ... > renderer := self rendererClass context: context. > self openDocument: document context: context. > renderer render: anObject; flush. > self closeDocument: document ] > > so I would like to change the method and split it up in two methods: > > WABuilder>>render: > > ^ self render: anObject withContext: WARenderContext new. > > and WABuilder>>render:withContext: > > WABuilder>>render: anObject > ^ String streamContents: [ :stream | > | context document renderer | > ... > context := aWARenderContext. > ... > renderer := self rendererClass context: context. > self openDocument: document context: context. > renderer render: anObject; flush. > self closeDocument: document ] > > Is that OK and conforming to your development rules? How do I proceed if it > is ok to implement? > > Regards > > Max > > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Hi Esteban,
the procedure is fine for small chunks that do not need a specific RenderContext. I am currently developing the tests for SeasideDynamicSVG package. There is everything already developed (own Canvas etc.) but I need to move it to Seaside 3.1. For that I am adding more testcases to ensure the stability. The decent problem for this case is, that an AnchorBrush is created related to the Context: anchorBrush := self context disableSVGAnchors ifTrue: [SVGDisabledAnchorBrush new] ifFalse: [SVGAnchorTag new]. ^self brush: anchorBrush So without having my own context I am not able to use the WABuilder to create a SVGDisabledAnchorTag. I could also create a subclass SVGBuilder but I think this feature may be useful also for WABuilder. Regards Max Am 25.08.2014 um 18:23 schrieb Esteban A. Maringolo <[hidden email]>: I don't know about SVG documents. But what I do to generate small _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
On Mon, Aug 25, 2014 at 6:31 PM, Maximilian Bareis <[hidden email]> wrote:
Just using that package right now. Very cool and works for me after fiddling around a bit. By any chance, do you have any sample with SeasideDynamicSVG-JQuery ?
This >>rawSVGContentOn: svg svg anchor callback: [ self info: 'Poked!' ] ;
target: '_top' ; with: [ svg circle
stroke: Color black; strokeWidth: 3 ; fill: Color yellow;
fillOpacity: 0.8 ; opacity: 0.6; center: 50@50;
radius: 30 ]. works but not really what I do want as it flashes the screen like a normal link.
Google didn't told me much. Phil
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
In reply to this post by Max Bareis
On Mon, Aug 25, 2014 at 6:16 PM, Maximilian Bareis <[hidden email]> wrote:
> Hi, > > I use WABuilder for creating small chunks of html-Code to test the SVGTags. > Unfortunately it is not possible to pass a RenderContext into > WABuilder>>render: > > WABuilder>>render: anObject > ^ String streamContents: [ :stream | > | context document renderer | > ... > context := WARenderContext new. > ... > renderer := self rendererClass context: context. > self openDocument: document context: context. > renderer render: anObject; flush. > self closeDocument: document ] > > so I would like to change the method and split it up in two methods: > > WABuilder>>render: > > ^ self render: anObject withContext: WARenderContext new. > > and WABuilder>>render:withContext: > > WABuilder>>render: anObject > ^ String streamContents: [ :stream | > | context document renderer | > ... > context := aWARenderContext. > ... > renderer := self rendererClass context: context. > self openDocument: document context: context. > renderer render: anObject; flush. > self closeDocument: document ] > > Is that OK and conforming to your development rules? How do I proceed if it > is ok to implement? Can you explain a bit why you need a custom WARenderContext? Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Am 25.08.2014 um 23:09 schrieb Philippe Marschall <[hidden email]>:
as I answered to Esteban, the creation of SVGAnchor depends on the state of the context. If the context has the state disableSVGAnchor the disabledAnchor is created otherwise the SVGAnchor is created. Why the disabled state is coupled to the context is beyond my knowledge, this needs to be answered by Johan or the creator of SVGCanvas>>anchor: If you think you do not need this feature in WABuilder I will subclass it to SVGBuilder. Regards Max _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
In reply to this post by philippeback
Am 25.08.2014 um 18:44 schrieb [hidden email]:
I have checked in a new version of SeasideDynamicSVG-Core /-jQuery /-Examples. There is a small example that changes svg tag attribute with the use of jquery. It is a simple example to show the main behavior of jQuery. It was tested on Seaside 3.1.2 only.
If you use anchor and callback, you do not use jQuery. For jQuery you normally use events like onClick, onChange and so on. Even for anchors you would use onClick instead of callback. It is possible to mix jQuery and Callback but for the beginning I suggest to stick on the events. Also have a look at the jQuery chapter in Seaside book Regards Max _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
On Tue, Aug 26, 2014 at 1:08 PM, Maximilian Bareis <[hidden email]> wrote:
Yeah, thanks. In the meantime, I managed to get it working: >>drawSVGPokeOn: svg | passenger |
svg anchor passenger: 'YOP'; onClick: ((svg jQuery ajax)
callback: [ :passengers | passenger := passengers first. self info: ('Poked!', passenger) ] passengers: (svg jQuery this);
script: [ :s | s << ('alert("Hello ', passenger, '")') js]); with: [
svg circle stroke: Color black; strokeWidth: 3 ;
fill: Color yellow; fillOpacity: 0.8 ; opacity: 0.6;
center: 50@50; radius: 30 ]. Additional question: what's the best way to get svg figures reflect the state of the model at the backend? Phil
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
In reply to this post by Max Bareis
Hi Max,
Are you just trying to improve testability here? Or do you need a different kind of rendering context? And do you need to be able to change it in a builder, or is it sufficient to have a WABuilder>>renderContextClass ^WARenderContext that you can override in a WABuilder subclass, similar to the rendererClass? Stephan _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Hi Stephan,
Actually I stumbled over this and was able to sail around, but in my opinion it is a design fault. The method WABuilder>>render: is no place to create objects, it is a place to pick together everything necessary for rendering and starting the process. There has to be a big reason why it should be forbidden to use one main part of the rendering process (the WARenderContext) only in new state. I am still asking, what is the reason to forbid using a WARenderContext with different attributes than a plain new one? WARenderContext has a property-attribute where you may store a lot of different properties that change the state of the context. Why is it forbidden to use them when using WABuilder? My first change suggestion was to create a second method with WABuilder>>render:withContext: and to change the current WABuilder>>render: to self render:html withContext:WARenderContext new. This would not change the current status. But it would enable Builder to accept also non-virgin WARenderContext and would move away a design fault. Regards Max Am 28.08.2014 um 12:39 schrieb Stephan Eggermont <[hidden email]>: > Hi Max, > > Are you just trying to improve testability here? > Or do you need a different kind of rendering context? > And do you need to be able to change it in a builder, > or is it sufficient to have a > WABuilder>>renderContextClass > ^WARenderContext > that you can override in a WABuilder subclass, > similar to the rendererClass? > > Stephan > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
In reply to this post by Max Bareis
On 25 Aug 2014, at 23:48, Maximilian Bareis <[hidden email]> wrote:
I’m not the creator of the package and it’s been some years ago I actually looked at its code. From looking at the code, it seems the anchors are being disabled when the svg is being exported to a file. I’m not sure if this is a technical requirement or a convenience to prevent urls from a seaside app being exported to a file (which does not make sense). If Holger (the original author) is still following this list, he might be able to comment…
I don’t understand the necessity to add an ability to put in your own rendercontext because: - you are still using a WARenderContext instance - you can manipulate the instance after constructing it: WAHtmlCanvas builder render: [ :html | html context disableSVGAnchors: true. ….] Would the above not be sufficient (and avoid other refactorings?) Johan _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Hi Johan,
perhaps I am a bit mistakable. It is not possible to put ANY render Context into WABuilder, because WABuilder always creates a new one. I do not want to create a custom Render Context. I want WABuilder to use the WARenderContext I have created and changed. see WABuilder>>render: anObject ^ String streamContents: [ :stream | | context document renderer | ... context := WARenderContext new. ... renderer := self rendererClass context: context. self openDocument: document context: context. renderer render: anObject; flush. self closeDocument: document ] My suggestion for a change is in the original mail (first one on thread). Regards Max Am 30.08.2014 um 18:00 schrieb Johan Brichau <[hidden email]>:
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Hi Max,
My suggestion was to set the properties after it was created by WABuilder. I was under the impression that would suit your use case for writing the test. Though adding the change as you suggest is not difficult, it is not consistent with the Seaside framework architecture as Seaside internally also does not allow you to specialize the rendercontext. Seaside always reference WARenderContext directly. So, if you can write the test by setting the properties in the beginning of your rendering code in the test, I have the impression it is a better fit. Let me know what you think Johan On 02 Sep 2014, at 13:48, Maximilian Bareis <[hidden email]> wrote:
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Free forum by Nabble | Edit this page |