From johan at inceptive.be Fri May 1 11:19:15 2015
From: johan at inceptive.be (Johan Brichau)
Date: Fri May 1 11:19:24 2015
Subject: [Seaside] Seaside3.0 on Pharo4
Message-ID: <4EC73757-90BE-4928-BA8D-4AB4FD89C288@inceptive.be>
Hi all,
For those of you who also need Seaside 3.0 to be on Pharo4 (like me), there is a 3.0.16 version that loads and works in Pharo4.
Obviously, this is a legacy release just to make Seaside 3.0 work with Grease1.1 on Pharo4.
Releases for the 3.1 (stable branch) or 3.2 (dev branch) were already made before, so this applies only to those wanting to maintain some project that uses Seaside 3.0 but want to upgrade to Pharo4.
See the CI server for all builds: https://ci.inria.fr/pharo-contribution/job/Seaside/
cheers
Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150501/cf9edf35/attachment-0001.htm
From johan at inceptive.be Fri May 1 12:11:39 2015
From: johan at inceptive.be (Johan Brichau)
Date: Fri May 1 12:11:44 2015
Subject: [Seaside] Jquery select then hide
In-Reply-To: <5540CD3D.4020606@drgeo.eu>
References: <553D6D3C.4050507@comcast.net>
<5540CD3D.4020606@drgeo.eu>
Message-ID: <06B12BDF-DACD-41B1-B1B1-E601F75963FC@inceptive.be>
> On 29 Apr 2015, at 14:23, Hilaire wrote:
>
> Le 28/04/2015 09:21, Johan Brichau a ?crit :
>> onChange: (html jQuery this value) equals: ?missis? asJavascript
>> then: (html jQuery: #maiden) show
>> then: (html jQuery: #maiden) hide)
>
> I understand the intend but not the syntax.
> I can see #then:else: message but no #equals: jquery instance
> But I am curious to learn how to
You?re right. JSObject>>equals: is an extension that is not in the standard Seaside package.
I?ll add it, but in the meantime, here?s the implementation:
JSObject>>equals: anObject
"Combine the receiver and anObject with a logical AND."
self addDecoration: (JSBinary new operator: '=='; statement: anObject)
From hilaire at drgeo.eu Sat May 2 09:42:04 2015
From: hilaire at drgeo.eu (Hilaire)
Date: Sat May 2 09:42:07 2015
Subject: [Seaside] Re: Seaside and Ajax
In-Reply-To:
References: <81EED03F-03AB-4163-AF91-167DC975B72C@inceptive.be>
Message-ID: <55449BEC.5090400@drgeo.eu>
Hi Johan,
Both options are fine but, at least for newbies, if Ajax tests are not
present in default Seaside installation, the Seaside welcome page should
not propose a link to test jquery and jquery-ui because they will broken
in that case and newbies may not fell good there.
Hilaire
Le 28/04/2015 09:24, Johan Brichau a ?crit :
> The ConfigurationOfSeaside3 for all 3.1 versions only loads Seaside core as a default. You need to add groups to your load expression if you want them.
> This was done with the mindset of customizable loads for everyone but ...
>
> Since people expected the inverse, the configuration for 3.2 has changed this and will load everything by default. If people want specific groups only, they can still do it. However, we should not change this for 3.1 as it might break other configurations, so we have to live with it until 3.2 is the stable version.
>
> Johan
>
>
>> On 25 Apr 2015, at 14:28, Hilaire wrote:
>>
>> One need to install at least Javascript-Test-Core and JQuery-Tests-Core.
>> Should it not be in the ConfigurationOfSeaside as the Seaside welcome
>> page comes with two links to jQuery and JQueryUI demos?
>>
>> Le 25/04/2015 11:47, Hilaire a ?crit :
>>> Le 22/04/2015 20:37, Johan Brichau a ?crit :
>>>> Take a look at the jQuery examples provided with Seaside
>>>> (http://localhost:8080/javascript/jquery) or the subclasses of
>>>> JQFunctionalTest.
>>>>
>>> Sadly this URL does not work from my Seaside previously installed on
>>> Pharo3 with the following script:
>>>
>>> Gofer new
>>>
>>> url:'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
>>> package: 'ConfigurationOfSeaside3';
>>> load.
>>> ((Smalltalk at: #ConfigurationOfSeaside3) project version: #stable) load.
>>>
>>>
>>> I guess some initialization was not properly done (the panel access was
>>> not present in the world menu as well).
>>>
>>> Thanks
>>>
>>> Hilaire
>>>
>>
>> --
>> Dr. Geo - http://drgeo.eu
>> iStoa - http://istoa.drgeo.eu
>>
>>
>> _______________________________________________
>> seaside mailing list
>> seaside@lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu
From hilaire at drgeo.eu Sat May 2 09:46:50 2015
From: hilaire at drgeo.eu (Hilaire)
Date: Sat May 2 09:47:01 2015
Subject: [Seaside] Re: Jquery select then hide
In-Reply-To: <06B12BDF-DACD-41B1-B1B1-E601F75963FC@inceptive.be>
References:
<553D6D3C.4050507@comcast.net> <5540CD3D.4020606@drgeo.eu>
<06B12BDF-DACD-41B1-B1B1-E601F75963FC@inceptive.be>
Message-ID:
Ok.
This way of definining Javascript snippet code is very Smalltalkish :)
I am wondering what is the pros and cons compared to just pure
javascript code integrated in a page as we do it for css descriptions.
Easier to debug? To protoype? But slower?
Anyway both options are there so it is nice.
Hilaire
Le 01/05/2015 14:11, Johan Brichau a ?crit :
> You?re right. JSObject>>equals: is an extension that is not in the standard Seaside package.
> I?ll add it, but in the meantime, here?s the implementation:
>
> JSObject>>equals: anObject
> "Combine the receiver and anObject with a logical AND."
>
> self addDecoration: (JSBinary new operator: '=='; statement: anObject)
--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu
From johan at inceptive.be Sun May 3 08:58:23 2015
From: johan at inceptive.be (Johan Brichau)
Date: Sun May 3 08:58:28 2015
Subject: [Seaside] Jquery select then hide
In-Reply-To:
References: <553D6D3C.4050507@comcast.net>
<5540CD3D.4020606@drgeo.eu>
<06B12BDF-DACD-41B1-B1B1-E601F75963FC@inceptive.be>
Message-ID: <4259003B-9B0A-45E5-A495-57D4A2D406DE@inceptive.be>
Generating pieces of Javascript code is only appropriate when they _need_ to be generated. For example, when you need to generate a Seaside-JQuery callback inside a javascript, only Seaside can generate the right url for the callback and injecting it into a piece of Javascript code is easily done with Seaside?s Javascript-generation logic.
html button
bePush;
onClick: (html jQuery ajax callback:[ self iWasClicked ]);
with: ?Click me!'
Seaside allows you to generate Javascript code, just like it allows you to generate html, but that should not tempt you to generate anything more than what needs to be generated. There is a conceptual difference between generating html (which is a declarative output) and Javascript code (which is procedural output), that makes it harder to understand. However, generating simple things around callbacks can be easy:
html button
bePush;
onClick: (html jQuery this) hide, (html jQuery ajax callback:[ self iWasClicked ]),(html jQuery this) show, html javascript return: false;
with: ?Click me!'
If you need pieces of javascript code that can be hand-written, then just write them down in a separate file and include it on the page.
updateRoot:
super updateRoot: aRoot.
aRoot javascript resourceUrl: ?myapp.js?
If that is too much for what you want to do, there is always JSStream:
html button
bePush;
onClick: (JSStream on: ?$(?#foobar?).html(?Someone clicked me?); return false;');
with: ?Click me!?
cheers
Johan
ps: The examples above are just to demonstrate code options, they do not show any useful interaction.
> On 02 May 2015, at 11:46, Hilaire wrote:
>
> Ok.
> This way of definining Javascript snippet code is very Smalltalkish :)
>
> I am wondering what is the pros and cons compared to just pure
> javascript code integrated in a page as we do it for css descriptions.
> Easier to debug? To protoype? But slower?
> Anyway both options are there so it is nice.
>
> Hilaire
>
> Le 01/05/2015 14:11, Johan Brichau a ?crit :
>> You?re right. JSObject>>equals: is an extension that is not in the standard Seaside package.
>> I?ll add it, but in the meantime, here?s the implementation:
>>
>> JSObject>>equals: anObject
>> "Combine the receiver and anObject with a logical AND."
>>
>> self addDecoration: (JSBinary new operator: '=='; statement: anObject)
>
>
> --
> Dr. Geo - http://drgeo.eu
> iStoa - http://istoa.drgeo.eu
>
>
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
From pbpublist at gmail.com Mon May 4 09:27:27 2015
From: pbpublist at gmail.com (Phil (list))
Date: Mon May 4 09:26:01 2015
Subject: [Seaside] 'Clean' URLs in Seaside
Message-ID: <1430731647.2544.11.camel@gmail.com>
I managed to get Seaside 2.x to use 'clean' URLs by following Ramon's
post here http://onsmalltalk.com/clean-urls-in-seaside/ a while back.
However, some things appear to have changed in 3.x and what needs to
change to get rid of the _k parameter (i.e. move it into a cookie) is
different now. So could anyone with experience in doing this in 3.x
share what's involved?
Also, it's understandable why passing this in the URL was the way to go
5+ years ago, but cookies are pretty widely accepted as requirements on
many sites these days. Is there some reason this hasn't been made a
simple config option as it was for the _s parameter? Seems like it
would be pretty popular...
Thanks,
Phil
From philippe.marschall at gmail.com Thu May 7 12:33:33 2015
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Thu May 7 12:33:35 2015
Subject: [Seaside] 'Clean' URLs in Seaside
In-Reply-To: <1430731647.2544.11.camel@gmail.com>
References: <1430731647.2544.11.camel@gmail.com>
Message-ID:
On Mon, May 4, 2015 at 11:27 AM, Phil (list) wrote:
> I managed to get Seaside 2.x to use 'clean' URLs by following Ramon's
> post here http://onsmalltalk.com/clean-urls-in-seaside/ a while back.
> However, some things appear to have changed in 3.x and what needs to
> change to get rid of the _k parameter (i.e. move it into a cookie) is
> different now. So could anyone with experience in doing this in 3.x
> share what's involved?
>
> Also, it's understandable why passing this in the URL was the way to go
> 5+ years ago, but cookies are pretty widely accepted as requirements on
> many sites these days.
Some countries also have cookie laws (yes, really) that don't apply
when you don't use cookies.
> Is there some reason this hasn't been made a
> simple config option as it was for the _s parameter? Seems like it
> would be pretty popular...
_k is used to identify the state snapshot. When you hit the back
button you need to get the old _k so that Seaside can revert the
component state. That's why it is technically not possible to
implement it with a cookie. Are you willing to give up state
snapshoting?
Cheers
Philippe
From emaringolo at gmail.com Thu May 7 12:55:30 2015
From: emaringolo at gmail.com (Esteban A. Maringolo)
Date: Thu May 7 12:56:13 2015
Subject: [Seaside] 'Clean' URLs in Seaside
In-Reply-To:
References: <1430731647.2544.11.camel@gmail.com>
Message-ID:
The shortcoming of using _s in a cookie is that you cannot open a
separate tab and start a new session. The session is "per browser"
(UA). Which is commonplace behavior these days, but I don't think it
will add much just moving the parameter from one place to another.
You can have bookmarkable URLs in your app though, but even when
Seaside supports that (via the #updateUrl: method), there is no
framework to automatically generate RESTful URIs and route back the
requests composing the component tree according to requested URL.
Regards,
Esteban A. Maringolo
2015-05-07 9:33 GMT-03:00 Philippe Marschall :
> On Mon, May 4, 2015 at 11:27 AM, Phil (list) wrote:
>> I managed to get Seaside 2.x to use 'clean' URLs by following Ramon's
>> post here http://onsmalltalk.com/clean-urls-in-seaside/ a while back.
>> However, some things appear to have changed in 3.x and what needs to
>> change to get rid of the _k parameter (i.e. move it into a cookie) is
>> different now. So could anyone with experience in doing this in 3.x
>> share what's involved?
>>
>> Also, it's understandable why passing this in the URL was the way to go
>> 5+ years ago, but cookies are pretty widely accepted as requirements on
>> many sites these days.
>
> Some countries also have cookie laws (yes, really) that don't apply
> when you don't use cookies.
>
>> Is there some reason this hasn't been made a
>> simple config option as it was for the _s parameter? Seems like it
>> would be pretty popular...
>
> _k is used to identify the state snapshot. When you hit the back
> button you need to get the old _k so that Seaside can revert the
> component state. That's why it is technically not possible to
> implement it with a cookie. Are you willing to give up state
> snapshoting?
>
> Cheers
> Philippe
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
From pbpublist at gmail.com Thu May 7 18:34:07 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu May 7 18:34:11 2015
Subject: [Seaside] 'Clean' URLs in Seaside
In-Reply-To:
References: <1430731647.2544.11.camel@gmail.com>
Message-ID: <1431023647.3025.51.camel@gmail.com>
Philippe,
On Thu, 2015-05-07 at 14:33 +0200, Philippe Marschall wrote:
> On Mon, May 4, 2015 at 11:27 AM, Phil (list) wrote:
> > I managed to get Seaside 2.x to use 'clean' URLs by following Ramon's
> > post here http://onsmalltalk.com/clean-urls-in-seaside/ a while back.
> > However, some things appear to have changed in 3.x and what needs to
> > change to get rid of the _k parameter (i.e. move it into a cookie) is
> > different now. So could anyone with experience in doing this in 3.x
> > share what's involved?
> >
> > Also, it's understandable why passing this in the URL was the way to go
> > 5+ years ago, but cookies are pretty widely accepted as requirements on
> > many sites these days.
>
> Some countries also have cookie laws (yes, really) that don't apply
> when you don't use cookies.
Good point... I'm so used to seeing those 'this site uses cookies'
warnings that I assumed the majority of EU (and other countries with
similar laws) sites just addressed it via disclosure. That is a very
good reason not to enable cookies by default.
>
> > Is there some reason this hasn't been made a
> > simple config option as it was for the _s parameter? Seems like it
> > would be pretty popular...
>
> _k is used to identify the state snapshot. When you hit the back
> button you need to get the old _k so that Seaside can revert the
> component state. That's why it is technically not possible to
> implement it with a cookie. Are you willing to give up state
> snapshoting?
>
Thanks for explaining this... I hadn't thought it through but now
understand why what I was asking for wouldn't work. To answer your
question: yes, I would be willing to give up the state snapshot to get
rid of the parameter. For this application (basically a simple database
lookup app), it looks like I can pass all the state needed via
#updateUrl: to get a bookmark-friendly URL so I think just dropping _k
entirely could work for me. How would I do that?
In the end, the best way I can think to describe what I'm trying to get
to is essentially an app that is 'RESTful enough' but still using the
Seaside component model to build its pages. I understand that I'd be
giving up the page to page state on the server side for anything that is
not manually passed. (i.e. the app may have 'foo', 'bar' and 'baz' state
variables but if it's only passed 1 or 2 of the 3 as parameters, use
defaults for whatever is missing and carry on)
> Cheers
> Philippe
> _______________________________________________
Thanks,
Phil
From pbpublist at gmail.com Thu May 7 19:08:07 2015
From: pbpublist at gmail.com (Phil (list))
Date: Thu May 7 19:08:11 2015
Subject: [Seaside] 'Clean' URLs in Seaside
In-Reply-To:
References: <1430731647.2544.11.camel@gmail.com>
Message-ID: <1431025687.3025.72.camel@gmail.com>
Esteban,
On Thu, 2015-05-07 at 09:55 -0300, Esteban A. Maringolo wrote:
> The shortcoming of using _s in a cookie is that you cannot open a
> separate tab and start a new session. The session is "per browser"
> (UA). Which is commonplace behavior these days, but I don't think it
> will add much just moving the parameter from one place to another.
>
That's an excellent point and I'll keep it in mind. For my current app,
I don't need to know much about a session other than as a way to tell
that one request is from a different person than another. Even then,
it's fairly generic and anonymous (i.e. think user preferences rather
than shopping carts)
> You can have bookmarkable URLs in your app though, but even when
> Seaside supports that (via the #updateUrl: method), there is no
> framework to automatically generate RESTful URIs and route back the
> requests composing the component tree according to requested URL.
>
True, you give up automatic URL handling. But for some apps, that's a
worthwhile trade-off without going the full RESTful route (at least as
described in the Seaside book)
> Regards,
>
> Esteban A. Maringolo
Thanks,
Phil
From philippe.marschall at gmail.com Tue May 12 06:07:42 2015
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Tue May 12 06:07:46 2015
Subject: [Seaside] 'Clean' URLs in Seaside
In-Reply-To: <1431023647.3025.51.camel@gmail.com>
References: <1430731647.2544.11.camel@gmail.com>
<1431023647.3025.51.camel@gmail.com>
Message-ID:
On Thu, May 7, 2015 at 8:34 PM, Phil (list) wrote:
> Philippe,
>
> On Thu, 2015-05-07 at 14:33 +0200, Philippe Marschall wrote:
>> On Mon, May 4, 2015 at 11:27 AM, Phil (list) wrote:
>> > I managed to get Seaside 2.x to use 'clean' URLs by following Ramon's
>> > post here http://onsmalltalk.com/clean-urls-in-seaside/ a while back.
>> > However, some things appear to have changed in 3.x and what needs to
>> > change to get rid of the _k parameter (i.e. move it into a cookie) is
>> > different now. So could anyone with experience in doing this in 3.x
>> > share what's involved?
>> >
>> > Also, it's understandable why passing this in the URL was the way to go
>> > 5+ years ago, but cookies are pretty widely accepted as requirements on
>> > many sites these days.
>>
>> Some countries also have cookie laws (yes, really) that don't apply
>> when you don't use cookies.
>
> Good point... I'm so used to seeing those 'this site uses cookies'
> warnings that I assumed the majority of EU (and other countries with
> similar laws) sites just addressed it via disclosure. That is a very
> good reason not to enable cookies by default.
>
>>
>> > Is there some reason this hasn't been made a
>> > simple config option as it was for the _s parameter? Seems like it
>> > would be pretty popular...
>>
>> _k is used to identify the state snapshot. When you hit the back
>> button you need to get the old _k so that Seaside can revert the
>> component state. That's why it is technically not possible to
>> implement it with a cookie. Are you willing to give up state
>> snapshoting?
>>
>
> Thanks for explaining this... I hadn't thought it through but now
> understand why what I was asking for wouldn't work. To answer your
> question: yes, I would be willing to give up the state snapshot to get
> rid of the parameter. For this application (basically a simple database
> lookup app), it looks like I can pass all the state needed via
> #updateUrl: to get a bookmark-friendly URL so I think just dropping _k
> entirely could work for me. How would I do that?
There is a way of doing this if you never use #callback: and a more
complicated one if you want to use #callback:. Time to learn some
Seaside :-)
1. You need a custom WAActionPhaseContinuation subclass that doesn't
make a state snapshot in #continue, maybe you can just get way with
implementing #captureState empty
2. You need a custom WARenderPhaseContinuation subclass that
implements #processRendering: so that the continuation is not added to
the action URL.
3. You need a custom WASession subclass that knows your two
continuations and implements #handleFiltered: so that it finds them
without _k. Is is a bit trickier to do if you do a redirect after
action processing. If you don't do a redirect reloading the page will
execute the last callback again.
4. if you want to use #callback: you have to implement a custom
WACallbackRegistry that "forgets" old callbacks
Having said all of that maybe it is easier to avoid sessions in your
case and use Seaside-REST and do your own rendering with:
WAHtmlCanvas builder
fullDocument: true;
render: MyPainter new
Just remember you can't do #callback: in this case either.
Cheers
Philippe
From jtuchel at objektfabrik.de Tue May 12 14:25:01 2015
From: jtuchel at objektfabrik.de (jtuchel@objektfabrik.de)
Date: Tue May 12 14:25:04 2015
Subject: [Seaside] Dynamically serving contents for an iFrame
Message-ID: <55520D3D.3070700@objektfabrik.de>
Hi there,
I am having trouble changing the contents of an iFrame with contents are
generated "dynamically".
What I want the page to do is change the contents of an iFrame when the
user clicks a link. There is an unorderedList of links that each
represent a document that can be displayed in the iFrame. The use of
iFrames seems to be the only way to display PDF documents inline in the
document.
Here is how far I got after quite some fiddling and trial&error:
first, in my renderContentOn: I bind an onclick handler to each link
that updates the src attribute of the iFrame:
fileCallback :=
html callbacks store: (WAActionCallback on: [self deliverFile]).
html document addLoadScript: (
'$(".documentLink").each(function(idx) {$(this).click(function(event){
$(".documentView iFrame").attr("src", "%1" + "&file=" + $(this).text());
event.preventDefault();})})'
bindWith: (html actionUrl withField: fileCallback))
The callback method looks like this:
deliverFile
| dateiName fields req aWAFile response document |
req := self requestContext request.
fields := req fields.
dateiName := (fields at: 'file').
aWAFile := "stuff that fetches the WAFile from a DB"
self requestContext respond: [:resp |
resp
document: aWAFile contents mimeType: aWAFile contentType fileName: aWAFile fileName]
This almost works.
When I click on the link, the src attribute of the iframe is being
updated and the callback method is invoked. The file is served and is
exactly the PDF document I expect.
BUT: instead of the iframe updating with the contents, the web browser
asks me whether I want to save the file or open it with an some local
application. That is of course not the expected behavior.
I see two areas which could be wrong:
a) The way the callback method changes the response to server the images
/ pdfs
I found some old messages on this list
(http://forum.world.st/Usage-of-WAIframeTag-tp88208.html) that use
returnResponse: , which is deprecated and even is not present in Pharo 3
any more.
b) the way I try to update the iframe by changing its src attribute
If I use set a static url in the .attr("src", someStaticUrl), the
new contents are shown as expected, so I guess the problem lies in the
callback somewhere...
Any ideas?
Joachim
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
From philippe.marschall at gmail.com Tue May 12 17:27:48 2015
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Tue May 12 17:27:50 2015
Subject: [Seaside] Dynamically serving contents for an iFrame
In-Reply-To: <55520D3D.3070700@objektfabrik.de>
References: <55520D3D.3070700@objektfabrik.de>
Message-ID:
On Tue, May 12, 2015 at 4:25 PM, jtuchel@objektfabrik.de
wrote:
> Hi there,
>
> I am having trouble changing the contents of an iFrame with contents are
> generated "dynamically".
>
> What I want the page to do is change the contents of an iFrame when the user
> clicks a link. There is an unorderedList of links that each represent a
> document that can be displayed in the iFrame. The use of iFrames seems to be
> the only way to display PDF documents inline in the document.
>
> Here is how far I got after quite some fiddling and trial&error:
>
> first, in my renderContentOn: I bind an onclick handler to each link that
> updates the src attribute of the iFrame:
>
> fileCallback :=
>
> html callbacks store: (WAActionCallback on: [self deliverFile]).
>
> html document addLoadScript: (
>
> '$(".documentLink").each(function(idx)
> {$(this).click(function(event){
>
> $(".documentView iFrame").attr("src", "%1" + "&file=" +
> $(this).text());
>
> event.preventDefault();})})'
>
> bindWith: (html actionUrl withField: fileCallback))
>
>
>
> The callback method looks like this:
>
> deliverFile
>
> | dateiName fields req aWAFile response document |
>
> req := self requestContext request.
>
> fields := req fields.
>
> dateiName := (fields at: 'file').
>
> aWAFile := "stuff that fetches the WAFile from a DB"
>
>
> self requestContext respond: [:resp |
>
> resp
>
> document: aWAFile contents mimeType: aWAFile contentType
> fileName: aWAFile fileName]
>
>
> This almost works.
>
> When I click on the link, the src attribute of the iframe is being updated
> and the callback method is invoked. The file is served and is exactly the
> PDF document I expect.
>
> BUT: instead of the iframe updating with the contents, the web browser asks
> me whether I want to save the file or open it with an some local
> application. That is of course not the expected behavior.
Have you tried the following HTTP header
Content-Disposition: inline
Cheers
Philippe
From pbpublist at gmail.com Tue May 12 18:44:15 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue May 12 18:44:14 2015
Subject: [Seaside] 'Clean' URLs in Seaside
In-Reply-To:
References: <1430731647.2544.11.camel@gmail.com>
<1431023647.3025.51.camel@gmail.com>
Message-ID: <1431456255.2637.15.camel@gmail.com>
On Tue, 2015-05-12 at 08:07 +0200, Philippe Marschall wrote:
> On Thu, May 7, 2015 at 8:34 PM, Phil (list) wrote:
> > Philippe,
> >
> > On Thu, 2015-05-07 at 14:33 +0200, Philippe Marschall wrote:
> >> On Mon, May 4, 2015 at 11:27 AM, Phil (list) wrote:
> >> > I managed to get Seaside 2.x to use 'clean' URLs by following Ramon's
> >> > post here http://onsmalltalk.com/clean-urls-in-seaside/ a while back.
> >> > However, some things appear to have changed in 3.x and what needs to
> >> > change to get rid of the _k parameter (i.e. move it into a cookie) is
> >> > different now. So could anyone with experience in doing this in 3.x
> >> > share what's involved?
> >> >
> >> > Also, it's understandable why passing this in the URL was the way to go
> >> > 5+ years ago, but cookies are pretty widely accepted as requirements on
> >> > many sites these days.
> >>
> >> Some countries also have cookie laws (yes, really) that don't apply
> >> when you don't use cookies.
> >
> > Good point... I'm so used to seeing those 'this site uses cookies'
> > warnings that I assumed the majority of EU (and other countries with
> > similar laws) sites just addressed it via disclosure. That is a very
> > good reason not to enable cookies by default.
> >
> >>
> >> > Is there some reason this hasn't been made a
> >> > simple config option as it was for the _s parameter? Seems like it
> >> > would be pretty popular...
> >>
> >> _k is used to identify the state snapshot. When you hit the back
> >> button you need to get the old _k so that Seaside can revert the
> >> component state. That's why it is technically not possible to
> >> implement it with a cookie. Are you willing to give up state
> >> snapshoting?
> >>
> >
> > Thanks for explaining this... I hadn't thought it through but now
> > understand why what I was asking for wouldn't work. To answer your
> > question: yes, I would be willing to give up the state snapshot to get
> > rid of the parameter. For this application (basically a simple database
> > lookup app), it looks like I can pass all the state needed via
> > #updateUrl: to get a bookmark-friendly URL so I think just dropping _k
> > entirely could work for me. How would I do that?
>
> There is a way of doing this if you never use #callback: and a more
> complicated one if you want to use #callback:. Time to learn some
> Seaside :-)
>
> 1. You need a custom WAActionPhaseContinuation subclass that doesn't
> make a state snapshot in #continue, maybe you can just get way with
> implementing #captureState empty
> 2. You need a custom WARenderPhaseContinuation subclass that
> implements #processRendering: so that the continuation is not added to
> the action URL.
> 3. You need a custom WASession subclass that knows your two
> continuations and implements #handleFiltered: so that it finds them
> without _k. Is is a bit trickier to do if you do a redirect after
> action processing. If you don't do a redirect reloading the page will
> execute the last callback again.
> 4. if you want to use #callback: you have to implement a custom
> WACallbackRegistry that "forgets" old callbacks
>
Fantastic... that definitely helps get me going in the right direction.
> Having said all of that maybe it is easier to avoid sessions in your
> case and use Seaside-REST and do your own rendering with:
>
> WAHtmlCanvas builder
> fullDocument: true;
> render: MyPainter new
>
> Just remember you can't do #callback: in this case either.
>
I've looked at this but it appears to be overkill for my needs, and much
more work in the long term from a maintenance standpoint. Going through
this exercise is giving me a good understanding of why this is
non-trivial in terms of providing a generic solution for a middle
path...
> Cheers
> Philippe
Thanks,
Phil
From jtuchel at objektfabrik.de Tue May 12 19:07:07 2015
From: jtuchel at objektfabrik.de (jtuchel@objektfabrik.de)
Date: Tue May 12 19:07:12 2015
Subject: [Seaside] Dynamically serving contents for an iFrame
In-Reply-To:
References: <55520D3D.3070700@objektfabrik.de>
Message-ID: <55524F5B.40203@objektfabrik.de>
H iPhilippe,
once again you nailed it.
At first it didn't work when I did this:
self requestContext respond: [:resp |
resp
inlineWithFileName: aWAFile fileName;
document: aWAFile contents mimeType: aWAFile contentType
fileName: aWAFile fileName;
doNotCache]
Then I tried:
self requestContext respond: [:resp |
resp
inlineWithFileName: aWAFile fileName;
document: aWAFile contents mimeType: aWAFile contentType;
doNotCache]
And it does work now.
In the first situation the Content-Disposition header was always
"attachment; filename=".
I'm not sure if that is a bug or not. Just wanted to let you know.
Again: Thank you very much!!!
Maybe we can have some Vino in Brescia? At least one glass is on me!
Joachim
Am 12.05.15 um 19:27 schrieb Philippe Marschall:
> On Tue, May 12, 2015 at 4:25 PM, jtuchel@objektfabrik.de
> wrote:
>> Hi there,
>>
>> I am having trouble changing the contents of an iFrame with contents are
>> generated "dynamically".
>>
>> What I want the page to do is change the contents of an iFrame when the user
>> clicks a link. There is an unorderedList of links that each represent a
>> document that can be displayed in the iFrame. The use of iFrames seems to be
>> the only way to display PDF documents inline in the document.
>>
>> Here is how far I got after quite some fiddling and trial&error:
>>
>> first, in my renderContentOn: I bind an onclick handler to each link that
>> updates the src attribute of the iFrame:
>>
>> fileCallback :=
>>
>> html callbacks store: (WAActionCallback on: [self deliverFile]).
>>
>> html document addLoadScript: (
>>
>> '$(".documentLink").each(function(idx)
>> {$(this).click(function(event){
>>
>> $(".documentView iFrame").attr("src", "%1" + "&file=" +
>> $(this).text());
>>
>> event.preventDefault();})})'
>>
>> bindWith: (html actionUrl withField: fileCallback))
>>
>>
>>
>> The callback method looks like this:
>>
>> deliverFile
>>
>> | dateiName fields req aWAFile response document |
>>
>> req := self requestContext request.
>>
>> fields := req fields.
>>
>> dateiName := (fields at: 'file').
>>
>> aWAFile := "stuff that fetches the WAFile from a DB"
>>
>>
>> self requestContext respond: [:resp |
>>
>> resp
>>
>> document: aWAFile contents mimeType: aWAFile contentType
>> fileName: aWAFile fileName]
>>
>>
>> This almost works.
>>
>> When I click on the link, the src attribute of the iframe is being updated
>> and the callback method is invoked. The file is served and is exactly the
>> PDF document I expect.
>>
>> BUT: instead of the iframe updating with the contents, the web browser asks
>> me whether I want to save the file or open it with an some local
>> application. That is of course not the expected behavior.
> Have you tried the following HTTP header
>
> Content-Disposition: inline
>
> Cheers
> Philippe
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
From pbpublist at gmail.com Tue May 12 19:19:23 2015
From: pbpublist at gmail.com (Phil (list))
Date: Tue May 12 19:19:20 2015
Subject: [Seaside] Not enough space / semaphore error
Message-ID: <1431458363.2637.22.camel@gmail.com>
I was doing some basic stress testing to see what would break first
under load and got an error: 'Not enough space for external objects, set
a larger size at startup' in VirtualMachine #maxExternalSemaphores:. I
could probably increase the limit (it appears to be 256 or so by
default), but the simulated load was far above what I'd ever reasonably
expect to see unless being (D)DOS'd so what I'd like to do instead is
limit the max number of sessions and/or requests that Seaside will
attempt to handle and ideally have any requests above the limit receive
a 5XX response... is this doable?
Thanks,
Phil
From philippe.marschall at gmail.com Wed May 13 09:03:24 2015
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Wed May 13 09:03:28 2015
Subject: [Seaside] Dynamically serving contents for an iFrame
In-Reply-To: <55524F5B.40203@objektfabrik.de>
References: <55520D3D.3070700@objektfabrik.de>
<55524F5B.40203@objektfabrik.de>
Message-ID:
On Tue, May 12, 2015 at 9:07 PM, jtuchel@objektfabrik.de
wrote:
> H iPhilippe,
>
> once again you nailed it.
>
> At first it didn't work when I did this:
>
>
> self requestContext respond: [:resp |
> resp
> inlineWithFileName: aWAFile fileName;
> document: aWAFile contents mimeType: aWAFile contentType
> fileName: aWAFile fileName;
> doNotCache]
>
> Then I tried:
>
> self requestContext respond: [:resp |
> resp
> inlineWithFileName: aWAFile fileName;
> document: aWAFile contents mimeType: aWAFile contentType;
> doNotCache]
>
>
> And it does work now.
>
>
> In the first situation the Content-Disposition header was always
> "attachment; filename=".
> I'm not sure if that is a bug or not. Just wanted to let you know.
This is a feature. "attachment" causes the download dialog to open,
"inline" just displays it. #fileName: triggers "attachement;
filename=".
> Again: Thank you very much!!!
>
> Maybe we can have some Vino in Brescia? At least one glass is on me!
:-)
Cheers
Philippe
From pdebruic at gmail.com Fri May 15 16:31:09 2015
From: pdebruic at gmail.com (Paul DeBruicker)
Date: Fri May 15 16:31:17 2015
Subject: [Seaside] what are the advantages to using Parasol for Selenium vs
just using the JS client?
Message-ID: <222DAE3C-5720-440A-B0FD-91BF4752FD50@gmail.com>
I'm trying to decide which one to start using for a project and can make arguments both ways.
For the people who use Parasol, why did you choose it vs using another language client outside of the image?
Thanks
Paul
From jupiter.jones at mail.com Fri May 15 22:08:20 2015
From: jupiter.jones at mail.com (Jupiter Jones)
Date: Fri May 15 22:08:30 2015
Subject: [Seaside] what are the advantages to using Parasol for Selenium
vs just using the JS client?
In-Reply-To: <222DAE3C-5720-440A-B0FD-91BF4752FD50@gmail.com>
References: <222DAE3C-5720-440A-B0FD-91BF4752FD50@gmail.com>
Message-ID:
Hi Paul,
If you mean writing tests for your seaside/amber app in another language outside the image, then that?s the main reason I chose Parasol/Selenium :)
My tests are written using SUnit and in Smalltalk (just just the rest of my tests and code), are packaged and loaded with Metacello (just like the rest of the application) and worked in both Pharo and GemStone.
Although I?m sure this is true of other solutions, I like how easy it is with Parasol/Selenium to have the same tests run on Safari, Chrome, Firefox, iOS and Android with one click on the test runner.
For testing, if Selenium (and Parasol?s control of selenium) doesn?t limit the ability to interact with the browser over any other solution, then the clincher for me was keeping it all in one language, and one environment.
Cheers,
J
PS. Maybe it?s just that I?m a Smalltalk addict, however, if my project can keep external solutions and other languages to a minimum, (Smalltalk rather than SQL, HTML Javascript, JSON, XML an so on) then all the better - the front end developers can support back end developers can support the testing team, etc. since they can all read and understand each others code. The only thing missing from the Smalltalk stack is an integrated way of working with SASS and Seaside/Amber? but getting off track.
> On 16 May 2015, at 2:31 am, Paul DeBruicker wrote:
>
> I'm trying to decide which one to start using for a project and can make arguments both ways.
>
>
> For the people who use Parasol, why did you choose it vs using another language client outside of the image?
>
>
> Thanks
>
> Paul_______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
From johan at inceptive.be Sat May 16 07:25:43 2015
From: johan at inceptive.be (Johan Brichau)
Date: Sat May 16 07:25:49 2015
Subject: [Seaside] what are the advantages to using Parasol for Selenium
vs just using the JS client?
In-Reply-To: <222DAE3C-5720-440A-B0FD-91BF4752FD50@gmail.com>
References: <222DAE3C-5720-440A-B0FD-91BF4752FD50@gmail.com>
Message-ID: <5E51452F-19C1-4C39-89BF-8FA9229292BE@inceptive.be>
Parasol gives you the ability to write complete end-to-end tests: simulate the actions of a user in the browser and verify the outcome on the Seaside backend.
This is because you have access to both the Seaside component state and, more importantly, the database used by your app, in the same environment where the test executes.
This means that:
- you can parameterize the tests with the database and the seaside state
- you can verify the outcome of the actions made in the web browser directly in the backend
- you can easily synchronize web browser actions and back-end operations from your unit tests
If you use a client in another language, you will have to find solutions to implement these interactions. Using Parasol, you can use what you had already set up to implement your application anyway.
These are the reasons we implemented and use Parasol, and why just using a binding implemented in another language is hardly an option.
cheers
Johan
> On 15 May 2015, at 18:31, Paul DeBruicker wrote:
>
> I'm trying to decide which one to start using for a project and can make arguments both ways.
>
>
> For the people who use Parasol, why did you choose it vs using another language client outside of the image?
>
>
> Thanks
>
> Paul_______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
From alexandre.bergel at me.com Sat May 16 15:12:58 2015
From: alexandre.bergel at me.com (Alexandre Bergel)
Date: Sat May 16 14:12:04 2015
Subject: [Seaside] Testing a seaside task and component?
Message-ID:
Hi!
I have a rather simple question regarding seaside.
Assuming I have a method MyTask>>go
How can I test it in a unit test?
Executing MyTask new go leads to the error: 'You can only #call: and #answer: from within a callback or a Task.'
Pity the Seaside distribution does not have the Sushi example and some tests.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
From johan at inceptive.be Sun May 17 10:58:20 2015
From: johan at inceptive.be (Johan Brichau)
Date: Sun May 17 10:58:25 2015
Subject: [Seaside] Testing a seaside task and component?
In-Reply-To:
References:
Message-ID: <88405EE8-FD83-45E7-B750-3727BC349D90@inceptive.be>
Hi Alex,
What exactly do you want to test by executing ?go? on the task?
There is the SeasideTesting project that allows to ?unit test? components but I am no longer maintaining that one in favour of Parasol.
I think it will even not load anymore in Pharo 4.
Now, you can ?unit test? components by making sure some dynamic variables are present when running the test (e.g. request, session, ?).
That?s how we converted a bunch of tests written using SeasideTesting to regular unit tests, though I would not recommend that approach when you start writing tests.
Johan
> On 16 May 2015, at 17:12, Alexandre Bergel wrote:
>
> Hi!
>
> I have a rather simple question regarding seaside.
> Assuming I have a method MyTask>>go
> How can I test it in a unit test?
> Executing MyTask new go leads to the error: 'You can only #call: and #answer: from within a callback or a Task.'
>
> Pity the Seaside distribution does not have the Sushi example and some tests.
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
From johan at inceptive.be Sun May 17 11:26:50 2015
From: johan at inceptive.be (Johan Brichau)
Date: Sun May 17 11:26:56 2015
Subject: [Seaside] Re: [Seaside-dev] Optimization / performance tuning
In-Reply-To: <1431826341.2791.21.camel@gmail.com>
References: <1431826341.2791.21.camel@gmail.com>
Message-ID: <7EB43BFB-D3BA-49D4-BD1F-53F23B584B50@inceptive.be>
I have never tried anything along those lines but you could decorate a component and keep the rendered html in that decoration. Something along:
renderContentOn: html
^ html html: (generatedHtml ifNil:[ generatedHtml := WAHtmlCanvas builder render:[:html2 | self renderNextOn: html2 ] ])
Though I?m seriously doubting any advantage in performance here by caching. This will only provide an advantage if the rendering code inside that cached component is slow.
If you need a page that is cached, try using a restful url in your app and turn on a front-end webserver page cache for that url.
Disclaimer: I also don?t know if the above really works and what caveats might arise. Keep us posted if you give it a try.
Johan
> On 17 May 2015, at 03:32, Phil (list) wrote:
>
> While the actual implementation would likely be application specific, I
> was wondering if there are any facilities in Seaside to help optimize
> Seaside application performance? For example, given an invariant
> component branch, is there any way to render once at the instance or
> session level and cache the resulting output rather than re-rendering
> each time the page is loaded? Any pointers to tips and techniques along
> these lines would be appreciated...
>
> Thanks,
> Phil
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
From pdebruic at gmail.com Sun May 17 14:49:32 2015
From: pdebruic at gmail.com (Paul DeBruicker)
Date: Sun May 17 15:06:39 2015
Subject: [Seaside] Re: Testing a seaside task and component?
In-Reply-To:
References:
Message-ID: <1431874172933-4826886.post@n4.nabble.com>
This was a helpful video about testing seaside components using Parasol:
https://www.youtube.com/watch?v=CoJ-Wnno6TY
abergel wrote
> Hi!
>
> I have a rather simple question regarding seaside.
> Assuming I have a method MyTask>>go
> How can I test it in a unit test?
> Executing MyTask new go leads to the error: 'You can only #call: and
> #answer: from within a callback or a Task.'
>
> Pity the Seaside distribution does not have the Sushi example and some
> tests.
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> _______________________________________________
> seaside mailing list
> seaside@.squeakfoundation
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
--
View this message in context: http://forum.world.st/Testing-a-seaside-task-and-component-tp4826759p4826886.html
Sent from the Seaside General mailing list archive at Nabble.com.
From pbpublist at gmail.com Sun May 17 19:54:35 2015
From: pbpublist at gmail.com (Phil (list))
Date: Sun May 17 19:54:27 2015
Subject: [Seaside] Re: [Seaside-dev] Optimization / performance tuning
In-Reply-To: <7EB43BFB-D3BA-49D4-BD1F-53F23B584B50@inceptive.be>
References: <1431826341.2791.21.camel@gmail.com>
<7EB43BFB-D3BA-49D4-BD1F-53F23B584B50@inceptive.be>
Message-ID: <1431892475.2275.44.camel@gmail.com>
On Sun, 2015-05-17 at 13:26 +0200, Johan Brichau wrote:
> I have never tried anything along those lines but you could decorate a component and keep the rendered html in that decoration. Something along:
>
> renderContentOn: html
> ^ html html: (generatedHtml ifNil:[ generatedHtml := WAHtmlCanvas builder render:[:html2 | self renderNextOn: html2 ] ])
>
That's an interesting idea... I'll give it a shot.
> Though I?m seriously doubting any advantage in performance here by caching. This will only provide an advantage if the rendering code inside that cached component is slow.
> If you need a page that is cached, try using a restful url in your app and turn on a front-end webserver page cache for that url.
>
If I were just looking at performance from the standpoint of a single
session, I'd agree that it probably wouldn't be worth the effort.
However, with multiple simultaneous sessions/users on a typical
cycle-starved VPS it is another story. A front-end cache wouldn't help
as only part of the page (i.e. the unchanging components) will be static
across multiple requests. (Note: the truly static content including css
and javascript is already being served by Apache)
> Disclaimer: I also don?t know if the above really works and what caveats might arise. Keep us posted if you give it a try.
>
> Johan
>
> > On 17 May 2015, at 03:32, Phil (list) wrote:
> >
> > While the actual implementation would likely be application specific, I
> > was wondering if there are any facilities in Seaside to help optimize
> > Seaside application performance? For example, given an invariant
> > component branch, is there any way to render once at the instance or
> > session level and cache the resulting output rather than re-rendering
> > each time the page is loaded? Any pointers to tips and techniques along
> > these lines would be appreciated...
> >
> > Thanks,
> > Phil
> >
> > _______________________________________________
> > seaside-dev mailing list
> > seaside-dev@lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
From johan at inceptive.be Mon May 18 07:24:21 2015
From: johan at inceptive.be (Johan Brichau)
Date: Mon May 18 07:24:05 2015
Subject: [Seaside] [Seaside-dev] Optimization / performance tuning
In-Reply-To: <1431892475.2275.44.camel@gmail.com>
References: <1431826341.2791.21.camel@gmail.com>
<7EB43BFB-D3BA-49D4-BD1F-53F23B584B50@inceptive.be>
<1431892475.2275.44.camel@gmail.com>
Message-ID: <8EC0F404-7B05-45CB-962D-95F4839F604A@inceptive.be>
> On 17 May 2015, at 21:54, Phil (list) wrote:
>
> On Sun, 2015-05-17 at 13:26 +0200, Johan Brichau wrote:
>> I have never tried anything along those lines but you could decorate a component and keep the rendered html in that decoration. Something along:
>>
>> renderContentOn: html
>> ^ html html: (generatedHtml ifNil:[ generatedHtml := WAHtmlCanvas builder render:[:html2 | self renderNextOn: html2 ] ])
>>
>
> That's an interesting idea... I'll give it a shot.
There are probably a lot of caveats in this case. For example, all generated links will refer to the wrong continuation in all but the first rendering pass.
The more I think about what I mentioned, the less I think it?s a good way to approach this, but it depends on what you want to do. I guess the hint about WABuilder is the only thing to remember from my reply :)
>> Though I?m seriously doubting any advantage in performance here by caching. This will only provide an advantage if the rendering code inside that cached component is slow.
>> If you need a page that is cached, try using a restful url in your app and turn on a front-end webserver page cache for that url.
>>
>
> If I were just looking at performance from the standpoint of a single
> session, I'd agree that it probably wouldn't be worth the effort.
Mind that the decoration solution is on a per-session state basis. So, every session will create its own cache.
> However, with multiple simultaneous sessions/users on a typical
> cycle-starved VPS it is another story. A front-end cache wouldn't help
> as only part of the page (i.e. the unchanging components) will be static
> across multiple requests. (Note: the truly static content including css
> and javascript is already being served by Apache)
I think you will want to write a specific component that implements its own cache and fetches the html. In that way, you can share generated html across sessions.
This would this boil down to writing a component that explicitly implements some caching system. Seaside does not know about it and thus mind that the remark about Seaside-generated links still holds: they refer to the session and continuation they are generated in. There are probably other issues, so it greatly depends on what you want to cache.
Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150518/9956c574/attachment.htm
From henrik.s.johansen at veloxit.no Mon May 18 10:33:47 2015
From: henrik.s.johansen at veloxit.no (Henrik Johansen)
Date: Mon May 18 10:33:52 2015
Subject: [Seaside] Calls to addParameter: in JQueryWidgetBox
Message-ID:
Hi!
A few of the widgets still use addParameter: (which used to be deprecated, now removed), instead of addField:.
It would be nice if someone with access to sthub/Seaside/JQueryWidgetBox has time to update the following packages:
JQWidgetBox-FancyBox-Core ( JQFancybox >> #callback: )
JQWidgetBox-JEditable-Core ( JQEditable >> #url )
JQWidgetBox-Autocomplete-Core ( JQWBAutocomplete >> #url )
Cheers,
Henry
From philippe.marschall at gmail.com Mon May 18 14:02:10 2015
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Mon May 18 14:02:13 2015
Subject: [Seaside] [Seaside-dev] Optimization / performance tuning
In-Reply-To: <8EC0F404-7B05-45CB-962D-95F4839F604A@inceptive.be>
References: <1431826341.2791.21.camel@gmail.com>
<7EB43BFB-D3BA-49D4-BD1F-53F23B584B50@inceptive.be>
<1431892475.2275.44.camel@gmail.com>
<8EC0F404-7B05-45CB-962D-95F4839F604A@inceptive.be>
Message-ID:
On Mon, May 18, 2015 at 9:24 AM, Johan Brichau wrote:
>
> On 17 May 2015, at 21:54, Phil (list) wrote:
>
> On Sun, 2015-05-17 at 13:26 +0200, Johan Brichau wrote:
>
> I have never tried anything along those lines but you could decorate a
> component and keep the rendered html in that decoration. Something along:
>
> renderContentOn: html
> ^ html html: (generatedHtml ifNil:[ generatedHtml := WAHtmlCanvas builder
> render:[:html2 | self renderNextOn: html2 ] ])
>
>
> That's an interesting idea... I'll give it a shot.
>
>
> There are probably a lot of caveats in this case. For example, all generated
> links will refer to the wrong continuation in all but the first rendering
> pass.
> The more I think about what I mentioned, the less I think it?s a good way to
> approach this, but it depends on what you want to do. I guess the hint about
> WABuilder is the only thing to remember from my reply :)
Right, in general you should not use #callback if you intend to cache
the result.
Cheers
Philippe
From pdebruic at gmail.com Fri May 22 22:10:54 2015
From: pdebruic at gmail.com (Paul DeBruicker)
Date: Fri May 22 22:28:38 2015
Subject: [Seaside] Re: fullcalendar on seaside 3.1 not work
In-Reply-To:
References: <321161275.782116.1421201128390.JavaMail.yahoo@jws10658.mail.bf1.yahoo.com>
<1421252258548-4799525.post@n4.nabble.com>
<1421252290896-4799526.post@n4.nabble.com>
Message-ID: <1432332654294-4828182.post@n4.nabble.com>
Hi Esteban,
Did you ever find time to version your full calendar wrapper?
Thanks
Paul
Esteban A. Maringolo wrote
> I'm using full calendar as a central part of an application using a basic
> wrapper.
>
> Let me see if I can version it and polish it a little.
> El ene 14, 2015 1:20 PM, "Paul DeBruicker" <
> pdebruic@
> > escribi?:
>
>> That should have said 'fix it today'.
>>
>>
>>
>> Paul DeBruicker wrote
>> > Hi Oswall,
>> >
>> > I'll take a look and see if I can fix it. It is a > 2 yr old version
>> of
>> > the FullCalendar, so the docs etc might be outdated. IF I get the
>> current
>> > version working in Seaside 3.1 on Pharo 3 will you work to update it to
>> > the latest JS version?
>> >
>> >
>> >
>> > Paul
>> > oswall wrote
>> >> Regards,
>> >>
>> >> I use Seaside 3.1, Pharo 3.0, on Ubuntu 14.04.I need to use
>> fullcalendar
>> >> on JQWidgetBox but does not work.
>> >> When I try to access it with url:
>> >> http://localhost:9090/jquery-widgets/fullcalendar
>> >>
>> >> Error message is:
>> >> MessageNotUnderstood: receiver of "encodeCollection:on:" is nil
>> >> Thanks for the support
>> >> Oswall
>> >> _______________________________________________
>> >> seaside mailing list
>>
>> >> seaside@.squeakfoundation
>>
>> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/fullcalendar-on-seaside-3-1-not-work-tp4799420p4799526.html
>> Sent from the Seaside General mailing list archive at Nabble.com.
>> _______________________________________________
>> seaside mailing list
>>
> seaside@.squeakfoundation
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
> _______________________________________________
> seaside mailing list
> seaside@.squeakfoundation
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
--
View this message in context: http://forum.world.st/fullcalendar-on-seaside-3-1-not-work-tp4799420p4828182.html
Sent from the Seaside General mailing list archive at Nabble.com.
From hilaire at drgeo.eu Sat May 23 09:32:08 2015
From: hilaire at drgeo.eu (Hilaire)
Date: Sat May 23 09:32:22 2015
Subject: [Seaside] greaseString on ScaledDecimal
Message-ID:
Hello,
-10.00s2 greaseString produce an unexpected 10.00, without the - sign.
Hilaire
--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu
From hilaire at drgeo.eu Sat May 23 09:40:11 2015
From: hilaire at drgeo.eu (Hilaire)
Date: Sat May 23 09:40:14 2015
Subject: [Seaside] Re: greaseString on ScaledDecimal
In-Reply-To:
References:
Message-ID: <55604AFB.9070600@drgeo.eu>
Le 23/05/2015 11:32, Hilaire a ?crit :
> Hello,
>
> -10.00s2 greaseString produce an unexpected 10.00, without the - sign.
>
> Hilaire
>
On Pharo 3.0, looks like this change is needed to get the sign:
ScaledDecimal>>greaseString
| converter |
converter := GRSignPrinter new, (GRNumberPrinter new precision: self
scale).
^ converter print: self
The it works:
-10.00s2 greaseString
=> '-10.00'
In which repo should it be pushed?
Hilaire
--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu
From philippe.marschall at gmail.com Sun May 24 09:45:02 2015
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Sun May 24 09:45:05 2015
Subject: [Seaside] Re: greaseString on ScaledDecimal
In-Reply-To: <55604AFB.9070600@drgeo.eu>
References:
<55604AFB.9070600@drgeo.eu>
Message-ID:
On Sat, May 23, 2015 at 11:40 AM, Hilaire wrote:
> Le 23/05/2015 11:32, Hilaire a ?crit :
>> Hello,
>>
>> -10.00s2 greaseString produce an unexpected 10.00, without the - sign.
>>
>> Hilaire
>>
>
> On Pharo 3.0, looks like this change is needed to get the sign:
>
> ScaledDecimal>>greaseString
> | converter |
> converter := GRSignPrinter new, (GRNumberPrinter new precision: self
> scale).
> ^ converter print: self
>
> The it works:
> -10.00s2 greaseString
> => '-10.00'
>
> In which repo should it be pushed?
http://smalltalkhub.com/#!/~Seaside/Seaside31
I don't know where you should report the issue
https://code.google.com/p/seaside/ redirects to
https://github.com/seasidest/googlecode-seaside-export.
Cheers
Philippe
From johan at inceptive.be Mon May 25 07:08:27 2015
From: johan at inceptive.be (Johan Brichau)
Date: Mon May 25 07:08:30 2015
Subject: [Seaside] greaseString on ScaledDecimal
In-Reply-To:
References: <55604AFB.9070600@drgeo.eu>
Message-ID: <13AE36C4-E45E-4EE4-9E17-AFCCAFC4FCBE@inceptive.be>
Hi Hilaire,
Thanks for spotting this.
I made your ticket and committed your code already
ticket: https://github.com/SeasideSt/Grease/issues/1
code in: http://www.smalltalkhub.com/#!/~Seaside/Grease11
> I don't know where you should report the issue
> https://code.google.com/p/seaside/ redirects to
> https://github.com/seasidest/googlecode-seaside-export .
Sorry about that one. This should be fixed now.
Please report issues for Grease on:
https://github.com/SeasideSt/Grease/issues/
Please report issues for Seaside on:
https://github.com/SeasideSt/Seaside/issues/
I?m adapting the website with this info now.
Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150525/35b97636/attachment.htm
From tulipe.moutarde at gmail.com Wed May 27 11:42:48 2015
From: tulipe.moutarde at gmail.com (=?UTF-8?Q?Fran=C3=A7ois_Stephany?=)
Date: Wed May 27 11:42:51 2015
Subject: [Seaside] Seaside3.0 on Pharo4
In-Reply-To: <4EC73757-90BE-4928-BA8D-4AB4FD89C288@inceptive.be>
References: <4EC73757-90BE-4928-BA8D-4AB4FD89C288@inceptive.be>
Message-ID:
Thanks Johan!
On Fri, May 1, 2015 at 1:19 PM, Johan Brichau wrote:
> Hi all,
>
> For those of you who also need Seaside 3.0 to be on Pharo4 (like me),
> there is a 3.0.16 version that loads and works in Pharo4.
> Obviously, this is a legacy release just to make Seaside 3.0 work with
> Grease1.1 on Pharo4.
>
> Releases for the 3.1 (stable branch) or 3.2 (dev branch) were already made
> before, so this applies only to those wanting to maintain some project that
> uses Seaside 3.0 but want to upgrade to Pharo4.
>
> See the CI server for all builds:
> https://ci.inria.fr/pharo-contribution/job/Seaside/
>
> cheers
> Johan
>
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150527/171a2d8d/attachment.htm
From hilaire at drgeo.eu Thu May 28 19:17:17 2015
From: hilaire at drgeo.eu (Hilaire)
Date: Thu May 28 19:17:45 2015
Subject: [Seaside] WAAnswerHandler strange style method
Message-ID:
Hello,
This class has its style method with a content:
style
^ 'color: red;'
and it produces error on the Firefox CSS console
Sorry I did not get my hand on GIThub to report it there.
Hilaire
--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu
From hilaire at drgeo.eu Thu May 28 20:03:21 2015
From: hilaire at drgeo.eu (Hilaire)
Date: Thu May 28 20:03:33 2015
Subject: [Seaside] Update a component after a Jquery
Message-ID:
Hi,
The datepicker event below updates the model and it implies an important
change in the component content (TableReport, etc). I think I kind of
need to refresh the page on the client.
Is it possible to do so from a callback fired from a jquery?
Thanks
Hilaire
html textInput
value: '1/1/2015';
callback: [ :value | self addMonth: value asDate asMonth];
script: (html jQuery new datepicker onSelect: html jQuery
ajax serializeThis).
--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu
From pdebruic at gmail.com Fri May 29 01:40:04 2015
From: pdebruic at gmail.com (Paul DeBruicker)
Date: Fri May 29 01:58:32 2015
Subject: [Seaside] Re: Update a component after a Jquery
In-Reply-To:
References:
Message-ID: <1432863604768-4829219.post@n4.nabble.com>
mail client coding but something like this should work:
(html jQuery new datepicker onSelect: (html jQuery
ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId') load
html: [:h | h render: myTable])).
HilaireFernandes wrote
> Hi,
>
> The datepicker event below updates the model and it implies an important
> change in the component content (TableReport, etc). I think I kind of
> need to refresh the page on the client.
> Is it possible to do so from a callback fired from a jquery?
>
> Thanks
>
> Hilaire
>
> html textInput
> value: '1/1/2015';
> callback: [ :value | self addMonth: value asDate asMonth];
> script: (html jQuery new datepicker onSelect: html jQuery
> ajax serializeThis).
>
> --
> Dr. Geo
> http://drgeo.eu
> http://google.com/+DrgeoEu
>
>
> _______________________________________________
> seaside mailing list
> seaside@.squeakfoundation
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
--
View this message in context: http://forum.world.st/Update-a-component-after-a-Jquery-tp4829158p4829219.html
Sent from the Seaside General mailing list archive at Nabble.com.
From marianopeck at gmail.com Fri May 29 02:03:55 2015
From: marianopeck at gmail.com (Mariano Martinez Peck)
Date: Fri May 29 02:03:57 2015
Subject: [Seaside] Re: Update a component after a Jquery
In-Reply-To: <1432863604768-4829219.post@n4.nabble.com>
References:
<1432863604768-4829219.post@n4.nabble.com>
Message-ID:
On Thu, May 28, 2015 at 10:40 PM, Paul DeBruicker
wrote:
> mail client coding but something like this should work:
>
>
> (html jQuery new datepicker onSelect: (html jQuery
> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId')
> *load html:* [:h | h render: myTable])).
>
>
>
Paul: Is there a difference between doing a "load html:" and "replaceWith:"
? In other words, doing:
(html jQuery new datepicker onSelect: (html jQuery
ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId')
*replaceWith:* [:h | h render: myTable]
Thanks,
>
>
>
> HilaireFernandes wrote
> > Hi,
> >
> > The datepicker event below updates the model and it implies an important
> > change in the component content (TableReport, etc). I think I kind of
> > need to refresh the page on the client.
> > Is it possible to do so from a callback fired from a jquery?
> >
> > Thanks
> >
> > Hilaire
> >
> > html textInput
> > value: '1/1/2015';
> > callback: [ :value | self addMonth: value asDate asMonth];
> > script: (html jQuery new datepicker onSelect: html jQuery
> > ajax serializeThis).
> >
> > --
> > Dr. Geo
> > http://drgeo.eu
> > http://google.com/+DrgeoEu
> >
> >
> > _______________________________________________
> > seaside mailing list
>
> > seaside@.squeakfoundation
>
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/Update-a-component-after-a-Jquery-tp4829158p4829219.html
> Sent from the Seaside General mailing list archive at Nabble.com.
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
--
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150528/c388950a/attachment-0001.htm
From jtuchel at objektfabrik.de Fri May 29 04:41:47 2015
From: jtuchel at objektfabrik.de (jtuchel@objektfabrik.de)
Date: Fri May 29 04:41:52 2015
Subject: [Seaside] Re: Update a component after a Jquery
In-Reply-To:
References: <1432863604768-4829219.post@n4.nabble.com>
Message-ID: <5567EE0B.9060906@objektfabrik.de>
Mariano,
load html: replaces the contents of a DOM node, so you need a render
method that only renders the children of a node or you will end up with,
say a DIV with itself as its frst child after load html:
replaceWith: replaces the element itself. So you can use the normal
rendering method to really replace the DOM node with what you render in
the block.
Note: I keep failing in my use of replaceWith: for whatever reason.
Joachim
Am 29.05.15 um 04:03 schrieb Mariano Martinez Peck:
>
>
> On Thu, May 28, 2015 at 10:40 PM, Paul DeBruicker > wrote:
>
> mail client coding but something like this should work:
>
>
> (html jQuery new datepicker onSelect: (html jQuery
> ajax serializeThis;onSuccess:((html jQuery id:
> 'myTableContainerId') *load
> html:* [:h | h render: myTable])).
>
>
>
> Paul: Is there a difference between doing a "load html:" and
> "replaceWith:" ? In other words, doing:
>
> (html jQuery new datepicker onSelect: (html jQuery
> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId')
> *replaceWith:* [:h | h render: myTable]
>
> Thanks,
>
>
>
>
>
> HilaireFernandes wrote
> > Hi,
> >
> > The datepicker event below updates the model and it implies an
> important
> > change in the component content (TableReport, etc). I think I
> kind of
> > need to refresh the page on the client.
> > Is it possible to do so from a callback fired from a jquery?
> >
> > Thanks
> >
> > Hilaire
> >
> > html textInput
> > value: '1/1/2015';
> > callback: [ :value | self addMonth: value asDate
> asMonth];
> > script: (html jQuery new datepicker onSelect: html
> jQuery
> > ajax serializeThis).
> >
> > --
> > Dr. Geo
> > http://drgeo.eu
> > http://google.com/+DrgeoEu
> >
> >
> > _______________________________________________
> > seaside mailing list
>
> > seaside@.squeakfoundation
>
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/Update-a-component-after-a-Jquery-tp4829158p4829219.html
> Sent from the Seaside General mailing list archive at Nabble.com.
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
>
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150529/5bdfc3fb/attachment.htm
From pdebruic at gmail.com Fri May 29 05:11:22 2015
From: pdebruic at gmail.com (Paul DeBruicker)
Date: Fri May 29 05:29:48 2015
Subject: [Seaside] Re: Update a component after a Jquery
In-Reply-To:
References:
<1432863604768-4829219.post@n4.nabble.com>
Message-ID: <1432876282916-4829230.post@n4.nabble.com>
Hi Mariano,
In addition to what Joachim said:
If you use #replaceWith: the html content must be known when the original
script is created, and therefore cannot reflect changes from the
datepicker's callback. With the 'load html:' the client sends an ajax
request for new html content (which could have changed because of the
datepicker's content), so you get up to date info in your DOM.
Mariano Martinez Peck wrote
> On Thu, May 28, 2015 at 10:40 PM, Paul DeBruicker <
> pdebruic@
> >
> wrote:
>
>> mail client coding but something like this should work:
>>
>>
>> (html jQuery new datepicker onSelect: (html jQuery
>> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId')
>> *load html:* [:h | h render: myTable])).
>>
>>
>>
> Paul: Is there a difference between doing a "load html:" and
> "replaceWith:"
> ? In other words, doing:
>
> (html jQuery new datepicker onSelect: (html jQuery
> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId')
> *replaceWith:* [:h | h render: myTable]
>
> Thanks,
>
>
>
>
>>
>>
>>
>> HilaireFernandes wrote
>> > Hi,
>> >
>> > The datepicker event below updates the model and it implies an
>> important
>> > change in the component content (TableReport, etc). I think I kind of
>> > need to refresh the page on the client.
>> > Is it possible to do so from a callback fired from a jquery?
>> >
>> > Thanks
>> >
>> > Hilaire
>> >
>> > html textInput
>> > value: '1/1/2015';
>> > callback: [ :value | self addMonth: value asDate asMonth];
>> > script: (html jQuery new datepicker onSelect: html jQuery
>> > ajax serializeThis).
>> >
>> > --
>> > Dr. Geo
>> > http://drgeo.eu
>> > http://google.com/+DrgeoEu
>> >
>> >
>> > _______________________________________________
>> > seaside mailing list
>>
>> > seaside@.squeakfoundation
>>
>> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Update-a-component-after-a-Jquery-tp4829158p4829219.html
>> Sent from the Seaside General mailing list archive at Nabble.com.
>> _______________________________________________
>> seaside mailing list
>>
> seaside@.squeakfoundation
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> seaside mailing list
> seaside@.squeakfoundation
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
--
View this message in context: http://forum.world.st/Update-a-component-after-a-Jquery-tp4829158p4829230.html
Sent from the Seaside General mailing list archive at Nabble.com.
From jtuchel at objektfabrik.de Fri May 29 05:42:53 2015
From: jtuchel at objektfabrik.de (jtuchel@objektfabrik.de)
Date: Fri May 29 05:42:57 2015
Subject: [Seaside] Re: Update a component after a Jquery
In-Reply-To: <1432876282916-4829230.post@n4.nabble.com>
References: <1432863604768-4829219.post@n4.nabble.com>
<1432876282916-4829230.post@n4.nabble.com>
Message-ID: <5567FC5D.8060209@objektfabrik.de>
So I'm glad I answered - learned why I was having troubles.
Thanks, Paul
Am 29.05.15 um 07:11 schrieb Paul DeBruicker:
> Hi Mariano,
>
> In addition to what Joachim said:
>
> If you use #replaceWith: the html content must be known when the original
> script is created, and therefore cannot reflect changes from the
> datepicker's callback. With the 'load html:' the client sends an ajax
> request for new html content (which could have changed because of the
> datepicker's content), so you get up to date info in your DOM.
>
>
>
>
> Mariano Martinez Peck wrote
>> On Thu, May 28, 2015 at 10:40 PM, Paul DeBruicker <
>> pdebruic@
>> >
>> wrote:
>>
>>> mail client coding but something like this should work:
>>>
>>>
>>> (html jQuery new datepicker onSelect: (html jQuery
>>> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId')
>>> *load html:* [:h | h render: myTable])).
>>>
>>>
>>>
>> Paul: Is there a difference between doing a "load html:" and
>> "replaceWith:"
>> ? In other words, doing:
>>
>> (html jQuery new datepicker onSelect: (html jQuery
>> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId')
>> *replaceWith:* [:h | h render: myTable]
>>
>> Thanks,
>>
>>
>>
>>
>>>
>>>
>>> HilaireFernandes wrote
>>>> Hi,
>>>>
>>>> The datepicker event below updates the model and it implies an
>>> important
>>>> change in the component content (TableReport, etc). I think I kind of
>>>> need to refresh the page on the client.
>>>> Is it possible to do so from a callback fired from a jquery?
>>>>
>>>> Thanks
>>>>
>>>> Hilaire
>>>>
>>>> html textInput
>>>> value: '1/1/2015';
>>>> callback: [ :value | self addMonth: value asDate asMonth];
>>>> script: (html jQuery new datepicker onSelect: html jQuery
>>>> ajax serializeThis).
>>>>
>>>> --
>>>> Dr. Geo
>>>> http://drgeo.eu
>>>> http://google.com/+DrgeoEu
>>>>
>>>>
>>>> _______________________________________________
>>>> seaside mailing list
>>>> seaside@.squeakfoundation
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://forum.world.st/Update-a-component-after-a-Jquery-tp4829158p4829219.html
>>> Sent from the Seaside General mailing list archive at Nabble.com.
>>> _______________________________________________
>>> seaside mailing list
>>>
>> seaside@.squeakfoundation
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>> _______________________________________________
>> seaside mailing list
>> seaside@.squeakfoundation
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
>
> --
> View this message in context: http://forum.world.st/Update-a-component-after-a-Jquery-tp4829158p4829230.html
> Sent from the Seaside General mailing list archive at Nabble.com.
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
From marianopeck at gmail.com Fri May 29 19:10:22 2015
From: marianopeck at gmail.com (Mariano Martinez Peck)
Date: Fri May 29 19:10:24 2015
Subject: [Seaside] Re: Update a component after a Jquery
In-Reply-To: <5567FC5D.8060209@objektfabrik.de>
References:
<1432863604768-4829219.post@n4.nabble.com>
<1432876282916-4829230.post@n4.nabble.com>
<5567FC5D.8060209@objektfabrik.de>
Message-ID:
Thank you both for the explanation. Today I learned something myself too.
On Fri, May 29, 2015 at 2:42 AM, jtuchel@objektfabrik.de <
jtuchel@objektfabrik.de> wrote:
> So I'm glad I answered - learned why I was having troubles.
>
> Thanks, Paul
>
> Am 29.05.15 um 07:11 schrieb Paul DeBruicker:
>
> Hi Mariano,
>>
>> In addition to what Joachim said:
>>
>> If you use #replaceWith: the html content must be known when the original
>> script is created, and therefore cannot reflect changes from the
>> datepicker's callback. With the 'load html:' the client sends an ajax
>> request for new html content (which could have changed because of the
>> datepicker's content), so you get up to date info in your DOM.
>>
>>
>>
>>
>> Mariano Martinez Peck wrote
>>
>>> On Thu, May 28, 2015 at 10:40 PM, Paul DeBruicker <
>>> pdebruic@
>>> >
>>> wrote:
>>>
>>> mail client coding but something like this should work:
>>>>
>>>>
>>>> (html jQuery new datepicker onSelect: (html jQuery
>>>> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId')
>>>> *load html:* [:h | h render: myTable])).
>>>>
>>>>
>>>>
>>>> Paul: Is there a difference between doing a "load html:" and
>>> "replaceWith:"
>>> ? In other words, doing:
>>>
>>> (html jQuery new datepicker onSelect: (html jQuery
>>> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId')
>>> *replaceWith:* [:h | h render: myTable]
>>>
>>> Thanks,
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> HilaireFernandes wrote
>>>>
>>>>> Hi,
>>>>>
>>>>> The datepicker event below updates the model and it implies an
>>>>>
>>>> important
>>>>
>>>>> change in the component content (TableReport, etc). I think I kind of
>>>>> need to refresh the page on the client.
>>>>> Is it possible to do so from a callback fired from a jquery?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Hilaire
>>>>>
>>>>> html textInput
>>>>> value: '1/1/2015';
>>>>> callback: [ :value | self addMonth: value asDate asMonth];
>>>>> script: (html jQuery new datepicker onSelect: html jQuery
>>>>> ajax serializeThis).
>>>>>
>>>>> --
>>>>> Dr. Geo
>>>>> http://drgeo.eu
>>>>> http://google.com/+DrgeoEu
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> seaside mailing list
>>>>> seaside@.squeakfoundation
>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://forum.world.st/Update-a-component-after-a-Jquery-tp4829158p4829219.html
>>>> Sent from the Seaside General mailing list archive at Nabble.com.
>>>> _______________________________________________
>>>> seaside mailing list
>>>>
>>>> seaside@.squeakfoundation
>>>
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>
>>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> seaside@.squeakfoundation
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Update-a-component-after-a-Jquery-tp4829158p4829230.html
>> Sent from the Seaside General mailing list archive at Nabble.com.
>> _______________________________________________
>> seaside mailing list
>> seaside@lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>
> --
> -----------------------------------------------------------------------
> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de
> Fliederweg 1 http://www.objektfabrik.de
> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
>
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
--
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150529/77864a7d/attachment-0001.htm
From hilaire at drgeo.eu Fri May 29 20:11:26 2015
From: hilaire at drgeo.eu (Hilaire)
Date: Fri May 29 20:11:31 2015
Subject: [Seaside] Re: Update a component after a Jquery
In-Reply-To: <1432863604768-4829219.post@n4.nabble.com>
References:
<1432863604768-4829219.post@n4.nabble.com>
Message-ID: <5568C7EE.6050505@drgeo.eu>
Le 29/05/2015 03:40, Paul DeBruicker a ?crit :
> mail client coding but something like this should work:
>
>
> (html jQuery new datepicker onSelect: (html jQuery
> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId') load
> html: [:h | h render: myTable])).
>
Thanks. I am not sure I can apply it.
The change in the model results in a new div element, containing a table
populated with content. Moreover depending on the imputed date, the div
element position may vary in the DOM tree. I think a whole refresh,
server side, may be simpler.
Hilaire
--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu
From johan at inceptive.be Sun May 31 09:55:50 2015
From: johan at inceptive.be (Johan Brichau)
Date: Sun May 31 09:55:57 2015
Subject: [Seaside] Update a component after a Jquery
In-Reply-To: <5568C7EE.6050505@drgeo.eu>
References:
<1432863604768-4829219.post@n4.nabble.com>
<5568C7EE.6050505@drgeo.eu>
Message-ID:
To trigger a full page refresh from a script:
html javascript refresh
So, if you want to do a full page request when selecting a date in the date picker:
html textInput
value: '1/1/2015';
callback: [ :value | self addMonth: value asDate asMonth];
script: (html jQuery new datepicker onSelect: html jQuery
ajax serializeThis; onComplete: (html javascript refresh)).
cheers
johan
> On 29 May 2015, at 22:11, Hilaire wrote:
>
> Le 29/05/2015 03:40, Paul DeBruicker a ?crit :
>> mail client coding but something like this should work:
>>
>>
>> (html jQuery new datepicker onSelect: (html jQuery
>> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId') load
>> html: [:h | h render: myTable])).
>>
>
> Thanks. I am not sure I can apply it.
>
> The change in the model results in a new div element, containing a table
> populated with content. Moreover depending on the imputed date, the div
> element position may vary in the DOM tree. I think a whole refresh,
> server side, may be simpler.
>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
> http://google.com/+DrgeoEu
>
> _______________________________________________
> seaside mailing list
> seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
From pdebruic at gmail.com Sun May 31 15:02:12 2015
From: pdebruic at gmail.com (Paul DeBruicker)
Date: Sun May 31 15:20:59 2015
Subject: [Seaside] Re: Update a component after a Jquery
In-Reply-To: <5568C7EE.6050505@drgeo.eu>
References:
<1432863604768-4829219.post@n4.nabble.com>
<5568C7EE.6050505@drgeo.eu>
Message-ID: <1433084532458-4829611.post@n4.nabble.com>
Hi Hilaire,
I'm sure you can do what you want without a full page refresh. Below is an
example. You choose one of 5 divs to update and the response and then
update two spots on the page at once.
renderContentOn: html
html select
list: #('a' 'b' 'c' 'd' 'e');
onChange:
(html jQuery ajax
serializeThis;
onComplete:
((html jQuery id: 'selected') load
html: [ :h |
h render: 'Last picked ' , chosenDiv greaseString.
h script: ((h jQuery id: chosenDiv) html: [ :r | r span:
DateAndTime now ]) ]));
selected: chosenDiv;
callback: [ :val | chosenDiv := val ].
html span
id: 'selected';
with: 'Last picked ' , chosenDiv greaseString.
#('a' 'b' 'c' 'd' 'e')
do: [ :ea |
html div
id: ea;
with: 'not chosen yet' ]
You can use the #onSelect: of the datepicker to trigger the change like I've
used the #onChange: of the select above.
Hope this helps.
Paul
HilaireFernandes wrote
> Le 29/05/2015 03:40, Paul DeBruicker a ?crit :
>> mail client coding but something like this should work:
>>
>>
>> (html jQuery new datepicker onSelect: (html jQuery
>> ajax serializeThis;onSuccess:((html jQuery id: 'myTableContainerId') load
>> html: [:h | h render: myTable])).
>>
>
> Thanks. I am not sure I can apply it.
>
> The change in the model results in a new div element, containing a table
> populated with content. Moreover depending on the imputed date, the div
> element position may vary in the DOM tree. I think a whole refresh,
> server side, may be simpler.
>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
> http://google.com/+DrgeoEu
>
> _______________________________________________
> seaside mailing list
> seaside@.squeakfoundation
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
--
View this message in context: http://forum.world.st/Update-a-component-after-a-Jquery-tp4829158p4829611.html
Sent from the Seaside General mailing list archive at Nabble.com.