WABuilder and Render Context

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

WABuilder and Render Context

Max Bareis
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
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

Esteban A. Maringolo
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
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

Max Bareis
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
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


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

philippeback
On Mon, Aug 25, 2014 at 6:31 PM, Maximilian Bareis <[hidden email]> wrote:
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.

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
 

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
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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

Philippe Marschall
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
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

Max Bareis
Am 25.08.2014 um 23:09 schrieb Philippe Marschall <[hidden email]>:

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?

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
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

Max Bareis
In reply to this post by philippeback
Am 25.08.2014 um 18:44 schrieb [hidden email]:



By any chance, do you have any sample with SeasideDynamicSVG-JQuery ?

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.


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
].


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
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

philippeback
On Tue, Aug 26, 2014 at 1:08 PM, Maximilian Bareis <[hidden email]> wrote:
Am 25.08.2014 um 18:44 schrieb [hidden email]:



By any chance, do you have any sample with SeasideDynamicSVG-JQuery ?

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.


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
].


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

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
 

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
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

Stephan Eggermont-3
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
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

Max Bareis
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
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

Johan Brichau-2
In reply to this post by Max Bareis

On 25 Aug 2014, at 23:48, Maximilian Bareis <[hidden email]> wrote:


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: 

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…

If you think you do not need this feature in WABuilder I will subclass it to SVGBuilder.

I’m not sure. You should have access to the renderContext from within your test and set the disabledAnchor flag without changing code to WABuilder.

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
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

Max Bareis
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]>:


On 25 Aug 2014, at 23:48, Maximilian Bareis <[hidden email]> wrote:


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: 

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…

If you think you do not need this feature in WABuilder I will subclass it to SVGBuilder.

I’m not sure. You should have access to the renderContext from within your test and set the disabledAnchor flag without changing code to WABuilder.

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


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: WABuilder and Render Context

Johan Brichau-2
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:

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]>:


On 25 Aug 2014, at 23:48, Maximilian Bareis <[hidden email]> wrote:


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: 

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…

If you think you do not need this feature in WABuilder I will subclass it to SVGBuilder.

I’m not sure. You should have access to the renderContext from within your test and set the disabledAnchor flag without changing code to WABuilder.

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

_______________________________________________
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