Ajax that uses server-side rendering

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

Ajax that uses server-side rendering

Iwan Vosloo
Hi there.

I am relatively new to Seaside and am uncertain about the best way to
solve some of the requirements we need to cover for a client. We do have
solutions for these, but they are tightly coupled to in-house
infrastructure and I think we can lean a lot from seeing how you guys
would have done it.

All of this is happening on Pharo 3.0, Seaside 3.1 and Magritte 3. Some
of the stuff is built using components and some using Magritte. We
prefer the latter.

Here is a relatively simple one:

We need to let a user choose a "type of ID document" in a dropdown.
Underneath this dropdown, a text input should appear via ajax (on change
of the dropdown), but it appears only for certain options of the dropdown.

This should happen via ajax, but we have one wish... we do not want to
use Pharo's javascript library wrappers to code the logic of HOW the DOM
should be changed in the browser. We'd rather fetch newly generated HTML
from the server via a "jQuery load", and replace a small chunk of the
form with this HTML. This way we let the original server-side
seaside/magritte code render that (changed) HTML snippet. (Some of our
screens are fairly complex, and we'd prefer to keep the logic for what
such a screen look like written once, and using Seaside/Magritte.)

Regards
- Iwan

PS: Is the seaside list the correct place to have this discussion? (as
opposed to the magritte list)


--
Reahl, the Python only web framework: http://www.reahl.org

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

Re: Ajax that uses server-side rendering

Paul DeBruicker
Does

html select
     ...
      onChange: (html jQuery id: 'textInputDiv') load html:[:h | self renderTextInputForSelectedOn: h]


html div id:'textInputDiv'


do what you want?


Iwan Vosloo wrote
Hi there.

I am relatively new to Seaside and am uncertain about the best way to
solve some of the requirements we need to cover for a client. We do have
solutions for these, but they are tightly coupled to in-house
infrastructure and I think we can lean a lot from seeing how you guys
would have done it.

All of this is happening on Pharo 3.0, Seaside 3.1 and Magritte 3. Some
of the stuff is built using components and some using Magritte. We
prefer the latter.

Here is a relatively simple one:

We need to let a user choose a "type of ID document" in a dropdown.
Underneath this dropdown, a text input should appear via ajax (on change
of the dropdown), but it appears only for certain options of the dropdown.

This should happen via ajax, but we have one wish... we do not want to
use Pharo's javascript library wrappers to code the logic of HOW the DOM
should be changed in the browser. We'd rather fetch newly generated HTML
from the server via a "jQuery load", and replace a small chunk of the
form with this HTML. This way we let the original server-side
seaside/magritte code render that (changed) HTML snippet. (Some of our
screens are fairly complex, and we'd prefer to keep the logic for what
such a screen look like written once, and using Seaside/Magritte.)

Regards
- Iwan

PS: Is the seaside list the correct place to have this discussion? (as
opposed to the magritte list)


--
Reahl, the Python only web framework: http://www.reahl.org

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

Re: Ajax that uses server-side rendering

Iwan Vosloo
On 15/07/2015 18:00, Paul DeBruicker wrote:

> Does
>
> html select
>       ...
>        onChange: (html jQuery id: 'textInputDiv') load html:[:h | self
> renderTextInputForSelectedOn: h]
>
>
> html div id:'textInputDiv'
>
>
> do what you want?

That's the general idea, but we'd like to do that using magritte. Given
an object (say a IdentificationDocument), with two descriptions - one
for the type of document and another for the expiry date we'd like to
control the visibility of the expiry date using magritte and rerender
the MAContainerComponent of this object with the jQuery load.

Thanks
-i

> Iwan Vosloo wrote
>> We need to let a user choose a "type of ID document" in a dropdown.
>> Underneath this dropdown, a text input should appear via ajax (on change
>> of the dropdown), but it appears only for certain options of the dropdown.
>>
>> This should happen via ajax, but we have one wish... we do not want to
>> use Pharo's javascript library wrappers to code the logic of HOW the DOM
>> should be changed in the browser. We'd rather fetch newly generated HTML
>> from the server via a "jQuery load", and replace a small chunk of the
>> form with this HTML. This way we let the original server-side
>> seaside/magritte code render that (changed) HTML snippet. (Some of our
>> screens are fairly complex, and we'd prefer to keep the logic for what
>> such a screen look like written once, and using Seaside/Magritte.)
>> nfo/seaside


--
Reahl, the Python only web framework: http://www.reahl.org

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

Re: Ajax that uses server-side rendering

Stephan Eggermont-3
On 16-07-15 08:24, Iwan Vosloo wrote:
> That's the general idea, but we'd like to do that using magritte. Given
> an object (say a IdentificationDocument), with two descriptions - one
> for the type of document and another for the expiry date we'd like to
> control the visibility of the expiry date using magritte and rerender
> the MAContainerComponent of this object with the jQuery load.

Then you might want to take a look at QCMagritte

Stephan


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

Re: Ajax that uses server-side rendering

Iwan Vosloo
On 16/07/2015 09:10, Stephan Eggermont wrote:

> On 16-07-15 08:24, Iwan Vosloo wrote:
>> That's the general idea, but we'd like to do that using magritte. Given
>> an object (say a IdentificationDocument), with two descriptions - one
>> for the type of document and another for the expiry date we'd like to
>> control the visibility of the expiry date using magritte and rerender
>> the MAContainerComponent of this object with the jQuery load.
>
> Then you might want to take a look at QCMagritte
>
> Stephan

I was afraid someone might say that... I do not have anything against
it, we are just trying to get all the code in an existing system to be
implemented consistently and QCMagritte would introduce a new way of
doing things. So, I am a bit reluctant to go there if all options with
straight Magritte have not been exhausted.

Would QCMagritte be the only way of achieving this, or just the better
way (vs Magritte)?

-Iwan

--
Reahl, the Python only web framework: http://www.reahl.org

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

Re: Ajax that uses server-side rendering

Stephan Eggermont-3
On 16-07-15 18:37, Iwan Vosloo wrote:

> On 16/07/2015 09:10, Stephan Eggermont wrote:
>> On 16-07-15 08:24, Iwan Vosloo wrote:
>>> That's the general idea, but we'd like to do that using magritte. Given
>>> an object (say a IdentificationDocument), with two descriptions - one
>>> for the type of document and another for the expiry date we'd like to
>>> control the visibility of the expiry date using magritte and rerender
>>> the MAContainerComponent of this object with the jQuery load.
>>
>> Then you might want to take a look at QCMagritte
>>
>> Stephan
>
> I was afraid someone might say that... I do not have anything against
> it, we are just trying to get all the code in an existing system to be
> implemented consistently and QCMagritte would introduce a new way of
> doing things. So, I am a bit reluctant to go there if all options with
> straight Magritte have not been exhausted.
>
> Would QCMagritte be the only way of achieving this, or just the better
> way (vs Magritte)?

QCMagritte is Magritte. You'll find one way of achieving what you
described in it. QCMagritte helps reducing duplication in the
descriptions and the builders.

Stephan

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside