10 Dec
2013
10 Dec
'13
11:50 a.m.
Hi all,
As you probably all know I have made a library (QC Magritte) that is build on top of
Magritte. I think it contains a lot of good add ons, maybe not structured enough. I am
trying to clean this code up, so it can be used easily by all. At this point I want to
move 2 things to Magritte. One as a change, and one as an add-on:
Change:
I would like to modify the basic MAContainerComponent to cache the description and
pre-process this with the description builders. I believe this is a missing hook in
Magritte. It is easy to add, and you do not notice it, if you do not use it. Also it
applies to all platforms, not just to Seaside, so if you think this is a good idea, I will
also modify the glamour container. The following problems can be solved using builders:
- separating display from the model. Now you have to set your custom component classes in
the model. It is much more elegant to do this from the display side. To add a builder it
can set the component class for each type of description (using visitors), for the
application you want to show.
- adding security. When you pre process the description before showing it, you can set
fields to readonly, or remove them entirely from the description if the user is not
allowed to see those properties.
Add-On:
I would ilke to add a package to Magritte3-AddOns called Magritte-Ajax. In this add-on I
will put the things that allow Ajax rendering of the components. Of course this is on top
of seaside and only valid for seaside, but that is why I think it should be an add-on and
not in the core. This would be:
- The AjaxMemento. (QCAjaxMemento)
- the extension methods for Ajax rendering.
- the extension methods for the added Ajax properties.
- A renderer, that renders the component, using Ajax. (QCGroupedFormRenderer)
Please let me know if you think this is a good idea. If you know a better place to do
these things, or to put the code, let me know.
If people have questions about QC-Magritte, please do not hesitate to ask them. I will try
to respond them fast and I will be available on Skype and Google Hangouts.
Cheers,
Diego
10 Dec
10 Dec
6:37 p.m.
On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi all,
As you probably all know I have made a library (QC Magritte) that is build
on top of Magritte. I think it contains a lot of good add ons, maybe not
structured enough. I am trying to clean this code up, so it can be used
easily by all. At this point I want to move 2 things to Magritte. One as a
change, and one as an add-on:
Change:
I would like to modify the basic MAContainerComponent to cache the
description and pre-process this with the description builders. I believe
this is a missing hook in Magritte. It is easy to add, and you do not
notice it, if you do not use it. Also it applies to all platforms, not just
to Seaside, so if you think this is a good idea, I will also modify the
glamour container. The following problems can be solved using builders:
- separating display from the model. Now you have to set your
custom component classes in the model. It is much more elegant to do this
from the display side. To add a builder it can set the component class for
each type of description (using visitors), for the application you want to
show.
- adding security. When you pre process the description before
showing it, you can set fields to readonly, or remove them entirely from
the description if the user is not allowed to see those properties.
Add-On:
I would ilke to add a package to Magritte3-AddOns called Magritte-Ajax. In
this add-on I will put the things that allow Ajax rendering of the
components. Of course this is on top of seaside and only valid for seaside,
but that is why I think it should be an add-on and not in the core. This
would be:
- The AjaxMemento. (QCAjaxMemento)
- the extension methods for Ajax rendering.
- the extension methods for the added Ajax properties.
All these for sure!
- A renderer, that renders the component,
using Ajax.
(QCGroupedFormRenderer)
Please let me know if you think this is a good idea. If you know a better
place to do these things, or to put the code, let me know.
Hi Diego,
First, thanks for pushing this stuff. I also have many extensions I did
myself to Magritte and so far I have them as subclasses or extension
methods etc. I need to clean them up before asking if they are useful. I
will send a separate mail for that.
For this particular email, I think that what you suggest makes sense.
Magritte-Ajax will depend on JQuery right?
I should have answered this email instead of the other one...anyway, I will
repeat it here. I would love if the first 3 points of the add on could be
used WITHOUT the QCGroupedFormRenderer. Or at least a class that doesn't
imply many changes. In other words...to plug that nice behavior with the
default rendered class: MATableRenderer.
would that be possible?
Thanks in advance,
If people have questions about QC-Magritte, please do
not hesitate to ask
them. I will try to respond them fast and I will be available on Skype and
Google Hangouts.
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
11 Dec
11 Dec
11:04 a.m.
Hi Mariano,
So basically you say yes, but my renderer does too much. Ok, I will try to make a stripped
version of this renderer.
Cheers,
Diego
On Dec 10, 2013, at 6:37 PM, Mariano Martinez Peck wrote:
On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi all,
As you probably all know I have made a library (QC Magritte) that is build on top of
Magritte. I think it contains a lot of good add ons, maybe not structured enough. I am
trying to clean this code up, so it can be used easily by all. At this point I want to
move 2 things to Magritte. One as a change, and one as an add-on:
Change:
I would like to modify the basic MAContainerComponent to cache the description and
pre-process this with the description builders. I believe this is a missing hook in
Magritte. It is easy to add, and you do not notice it, if you do not use it. Also it
applies to all platforms, not just to Seaside, so if you think this is a good idea, I will
also modify the glamour container. The following problems can be solved using builders:
- separating display from the model. Now you have to set your custom component
classes in the model. It is much more elegant to do this from the display side. To add a
builder it can set the component class for each type of description (using visitors), for
the application you want to show.
- adding security. When you pre process the description before showing it, you
can set fields to readonly, or remove them entirely from the description if the user is
not allowed to see those properties.
Add-On:
I would ilke to add a package to Magritte3-AddOns called Magritte-Ajax. In this add-on I
will put the things that allow Ajax rendering of the components. Of course this is on top
of seaside and only valid for seaside, but that is why I think it should be an add-on and
not in the core. This would be:
- The AjaxMemento. (QCAjaxMemento)
- the extension methods for Ajax rendering.
- the extension methods for the added Ajax properties.
All these for sure!
- A renderer, that renders the component, using Ajax. (QCGroupedFormRenderer)
Please let me know if you think this is a good idea. If you know a better place to do
these things, or to put the code, let me know.
Hi Diego,
First, thanks for pushing this stuff. I also have many extensions I did myself to
Magritte and so far I have them as subclasses or extension methods etc. I need to clean
them up before asking if they are useful. I will send a separate mail for that.
For this particular email, I think that what you suggest makes sense. Magritte-Ajax will
depend on JQuery right?
I should have answered this email instead of the other one...anyway, I will repeat it
here. I would love if the first 3 points of the add on could be used WITHOUT the
QCGroupedFormRenderer. Or at least a class that doesn't imply many changes. In other
words...to plug that nice behavior with the default rendered class: MATableRenderer.
would that be possible?
Thanks in advance,
If people have questions about QC-Magritte, please do not hesitate to ask them. I will
try to respond them fast and I will be available on Skype and Google Hangouts.
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
1:16 p.m.
On Wed, Dec 11, 2013 at 7:04 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi Mariano,
So basically you say yes, but my renderer does too much. Ok, I will try to
make a stripped version of this renderer.
Thanks Diego. Yes, or have a minimal render with the minimal needed
behavior for such a features, or at least to be able to plug that features
over the default render.
Thanks!! let me know if I can help with something. I can start using it
right ahead :)
Cheers,
Diego
On Dec 10, 2013, at 6:37 PM, Mariano Martinez Peck wrote:
On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
--
Mariano
http://marianopeck.wordpress.com
Hi all,
As you probably all know I have made a library (QC Magritte) that is
build on top of Magritte. I think it contains a lot of good add ons, maybe
not structured enough. I am trying to clean this code up, so it can be used
easily by all. At this point I want to move 2 things to Magritte. One as a
change, and one as an add-on:
Change:
I would like to modify the basic MAContainerComponent to cache the
description and pre-process this with the description builders. I believe
this is a missing hook in Magritte. It is easy to add, and you do not
notice it, if you do not use it. Also it applies to all platforms, not just
to Seaside, so if you think this is a good idea, I will also modify the
glamour container. The following problems can be solved using builders:
- separating display from the model. Now you have to set your
custom component classes in the model. It is much more elegant to do this
from the display side. To add a builder it can set the component class for
each type of description (using visitors), for the application you want to
show.
- adding security. When you pre process the description before
showing it, you can set fields to readonly, or remove them entirely from
the description if the user is not allowed to see those properties.
Add-On:
I would ilke to add a package to Magritte3-AddOns called Magritte-Ajax.
In this add-on I will put the things that allow Ajax rendering of the
components. Of course this is on top of seaside and only valid for seaside,
but that is why I think it should be an add-on and not in the core. This
would be:
- The AjaxMemento. (QCAjaxMemento)
- the extension methods for Ajax rendering.
- the extension methods for the added Ajax properties.
All these for sure!
- A renderer, that renders the component,
using Ajax.
(QCGroupedFormRenderer)
Please let me know if you think this is a good idea. If you know a better
place to do these things, or to put the code, let me know.
Hi Diego,
First, thanks for pushing this stuff. I also have many extensions I did
myself to Magritte and so far I have them as subclasses or extension
methods etc. I need to clean them up before asking if they are useful. I
will send a separate mail for that.
For this particular email, I think that what you suggest makes sense.
Magritte-Ajax will depend on JQuery right?
I should have answered this email instead of the other one...anyway, I
will repeat it here. I would love if the first 3 points of the add on could
be used WITHOUT the QCGroupedFormRenderer. Or at least a class that
doesn't imply many changes. In other words...to plug that nice behavior
with the default rendered class: MATableRenderer.
would that be possible?
Thanks in advance,
If people have questions about QC-Magritte,
please do not hesitate to ask
them. I will try to respond them fast and I will be available on Skype and
Google Hangouts.
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
1:25 p.m.
Hi Mariano,
Ok, I have extracted the functionality you need in QC-Magritte-Ajax. It contains a custom
renderer to override the table renderer (QCAjaxTableRenderer). Note that it re-renders the
entire table on each change … so it does not need groups. Unfortunately it does not keep
the focus, this is the only thing that bugs me, and rendering more of the page, gives a
bigger chance of giving the user some annoyance over this.
The package QC-Magritte-Ajax should work stand alone, I did not test this yet.
Cheers,
Diego
On Dec 10, 2013, at 6:37 PM, Mariano Martinez Peck wrote:
On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi all,
As you probably all know I have made a library (QC Magritte) that is build on top of
Magritte. I think it contains a lot of good add ons, maybe not structured enough. I am
trying to clean this code up, so it can be used easily by all. At this point I want to
move 2 things to Magritte. One as a change, and one as an add-on:
Change:
I would like to modify the basic MAContainerComponent to cache the description and
pre-process this with the description builders. I believe this is a missing hook in
Magritte. It is easy to add, and you do not notice it, if you do not use it. Also it
applies to all platforms, not just to Seaside, so if you think this is a good idea, I will
also modify the glamour container. The following problems can be solved using builders:
- separating display from the model. Now you have to set your custom component
classes in the model. It is much more elegant to do this from the display side. To add a
builder it can set the component class for each type of description (using visitors), for
the application you want to show.
- adding security. When you pre process the description before showing it, you
can set fields to readonly, or remove them entirely from the description if the user is
not allowed to see those properties.
Add-On:
I would ilke to add a package to Magritte3-AddOns called Magritte-Ajax. In this add-on I
will put the things that allow Ajax rendering of the components. Of course this is on top
of seaside and only valid for seaside, but that is why I think it should be an add-on and
not in the core. This would be:
- The AjaxMemento. (QCAjaxMemento)
- the extension methods for Ajax rendering.
- the extension methods for the added Ajax properties.
All these for sure!
- A renderer, that renders the component, using Ajax. (QCGroupedFormRenderer)
Please let me know if you think this is a good idea. If you know a better place to do
these things, or to put the code, let me know.
Hi Diego,
First, thanks for pushing this stuff. I also have many extensions I did myself to
Magritte and so far I have them as subclasses or extension methods etc. I need to clean
them up before asking if they are useful. I will send a separate mail for that.
For this particular email, I think that what you suggest makes sense. Magritte-Ajax will
depend on JQuery right?
I should have answered this email instead of the other one...anyway, I will repeat it
here. I would love if the first 3 points of the add on could be used WITHOUT the
QCGroupedFormRenderer. Or at least a class that doesn't imply many changes. In other
words...to plug that nice behavior with the default rendered class: MATableRenderer.
would that be possible?
Thanks in advance,
If people have questions about QC-Magritte, please do not hesitate to ask them. I will
try to respond them fast and I will be available on Skype and Google Hangouts.
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
2:07 p.m.
On Wed, Dec 11, 2013 at 9:25 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi Mariano,
Ok, I have extracted the functionality you need in QC-Magritte-Ajax. It
contains a custom renderer to override the table renderer
(QCAjaxTableRenderer). Note that it re-renders the entire table on each
change … so it does not need groups. Unfortunately it does not keep the
focus, this is the only thing that bugs me, and rendering more of the page,
gives a bigger chance of giving the user some annoyance over this.
The package QC-Magritte-Ajax should work stand alone, I did not test this
yet.
Hi Diego, thanks for doing that! A quick tests shows me that it works! The
only small detail is that
QCAjaxMemento #procesHiddenFor: aDescription value: anObject sends
#hiddenValues to the description and #readUsing: sends #isWrapped. We
don't have either of them.
So I think we either move those 2 to QC-Magritte-Ajax or we put a
dependency to QC-Magritte-Other (and hence also QC-Magritte-Core). Maybe
the first option is easier.
In my particular use-case, I usually have many combos lists in which the
"options and values" comes from a DB query. Even if I do have caches etc I
would try to avoid doing such a queries each time a field is modified. So I
will see if I can adapt QCAjaxTableRenderer to perform the ajax only for
groups (as it was the previous render). I think that having ALSO such
feature also in QCAjaxTableRenderer would be awesome. Then we can have
simple flags to update all fields or update only by groups :)
Thanks Diego, it is good to see Magritte-Seaside moving forward!
Cheers,
Diego
On Dec 10, 2013, at 6:37 PM, Mariano Martinez Peck wrote:
On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
--
Mariano
http://marianopeck.wordpress.com
Hi all,
As you probably all know I have made a library (QC Magritte) that is
build on top of Magritte. I think it contains a lot of good add ons, maybe
not structured enough. I am trying to clean this code up, so it can be used
easily by all. At this point I want to move 2 things to Magritte. One as a
change, and one as an add-on:
Change:
I would like to modify the basic MAContainerComponent to cache the
description and pre-process this with the description builders. I believe
this is a missing hook in Magritte. It is easy to add, and you do not
notice it, if you do not use it. Also it applies to all platforms, not just
to Seaside, so if you think this is a good idea, I will also modify the
glamour container. The following problems can be solved using builders:
- separating display from the model. Now you have to set your
custom component classes in the model. It is much more elegant to do this
from the display side. To add a builder it can set the component class for
each type of description (using visitors), for the application you want to
show.
- adding security. When you pre process the description before
showing it, you can set fields to readonly, or remove them entirely from
the description if the user is not allowed to see those properties.
Add-On:
I would ilke to add a package to Magritte3-AddOns called Magritte-Ajax.
In this add-on I will put the things that allow Ajax rendering of the
components. Of course this is on top of seaside and only valid for seaside,
but that is why I think it should be an add-on and not in the core. This
would be:
- The AjaxMemento. (QCAjaxMemento)
- the extension methods for Ajax rendering.
- the extension methods for the added Ajax properties.
All these for sure!
- A renderer, that renders the component,
using Ajax.
(QCGroupedFormRenderer)
Please let me know if you think this is a good idea. If you know a better
place to do these things, or to put the code, let me know.
Hi Diego,
First, thanks for pushing this stuff. I also have many extensions I did
myself to Magritte and so far I have them as subclasses or extension
methods etc. I need to clean them up before asking if they are useful. I
will send a separate mail for that.
For this particular email, I think that what you suggest makes sense.
Magritte-Ajax will depend on JQuery right?
I should have answered this email instead of the other one...anyway, I
will repeat it here. I would love if the first 3 points of the add on could
be used WITHOUT the QCGroupedFormRenderer. Or at least a class that
doesn't imply many changes. In other words...to plug that nice behavior
with the default rendered class: MATableRenderer.
would that be possible?
Thanks in advance,
If people have questions about QC-Magritte,
please do not hesitate to ask
them. I will try to respond them fast and I will be available on Skype and
Google Hangouts.
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
2:38 p.m.
Hi Mariano,
Yes, I will move those to QC-Magritte-Ajax (done). QC-Magritte-Other is a collection of
all the things that do not have a good place yet.
One thing in trying do separate them into groups: a table can only re-render a single row,
or an entire table. So you will have to create subtables, or some other structure to allow
that in Ajax.
And I see I missed a question. Yes, QC-Magritte-Ajax depends on JQuery.
Cheers,
Diego
On Dec 11, 2013, at 2:07 PM, Mariano Martinez Peck wrote:
On Wed, Dec 11, 2013 at 9:25 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi Mariano,
Ok, I have extracted the functionality you need in QC-Magritte-Ajax. It contains a custom
renderer to override the table renderer (QCAjaxTableRenderer). Note that it re-renders the
entire table on each change … so it does not need groups. Unfortunately it does not keep
the focus, this is the only thing that bugs me, and rendering more of the page, gives a
bigger chance of giving the user some annoyance over this.
The package QC-Magritte-Ajax should work stand alone, I did not test this yet.
Hi Diego, thanks for doing that! A quick tests shows me that it works! The only small
detail is that
QCAjaxMemento #procesHiddenFor: aDescription value: anObject sends #hiddenValues to the
description and #readUsing: sends #isWrapped. We don't have either of them.
So I think we either move those 2 to QC-Magritte-Ajax or we put a dependency to
QC-Magritte-Other (and hence also QC-Magritte-Core). Maybe the first option is easier.
In my particular use-case, I usually have many combos lists in which the "options
and values" comes from a DB query. Even if I do have caches etc I would try to avoid
doing such a queries each time a field is modified. So I will see if I can adapt
QCAjaxTableRenderer to perform the ajax only for groups (as it was the previous render). I
think that having ALSO such feature also in QCAjaxTableRenderer would be awesome. Then we
can have simple flags to update all fields or update only by groups :)
Thanks Diego, it is good to see Magritte-Seaside moving forward!
Cheers,
Diego
On Dec 10, 2013, at 6:37 PM, Mariano Martinez Peck wrote:
On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi all,
As you probably all know I have made a library (QC Magritte) that is build on top of
Magritte. I think it contains a lot of good add ons, maybe not structured enough. I am
trying to clean this code up, so it can be used easily by all. At this point I want to
move 2 things to Magritte. One as a change, and one as an add-on:
Change:
I would like to modify the basic MAContainerComponent to cache the description and
pre-process this with the description builders. I believe this is a missing hook in
Magritte. It is easy to add, and you do not notice it, if you do not use it. Also it
applies to all platforms, not just to Seaside, so if you think this is a good idea, I will
also modify the glamour container. The following problems can be solved using builders:
- separating display from the model. Now you have to set your custom component
classes in the model. It is much more elegant to do this from the display side. To add a
builder it can set the component class for each type of description (using visitors), for
the application you want to show.
- adding security. When you pre process the description before showing it, you
can set fields to readonly, or remove them entirely from the description if the user is
not allowed to see those properties.
Add-On:
I would ilke to add a package to Magritte3-AddOns called Magritte-Ajax. In this add-on I
will put the things that allow Ajax rendering of the components. Of course this is on top
of seaside and only valid for seaside, but that is why I think it should be an add-on and
not in the core. This would be:
- The AjaxMemento. (QCAjaxMemento)
- the extension methods for Ajax rendering.
- the extension methods for the added Ajax properties.
All these for sure!
- A renderer, that renders the component, using Ajax. (QCGroupedFormRenderer)
Please let me know if you think this is a good idea. If you know a better place to do
these things, or to put the code, let me know.
Hi Diego,
First, thanks for pushing this stuff. I also have many extensions I did myself to
Magritte and so far I have them as subclasses or extension methods etc. I need to clean
them up before asking if they are useful. I will send a separate mail for that.
For this particular email, I think that what you suggest makes sense. Magritte-Ajax will
depend on JQuery right?
I should have answered this email instead of the other one...anyway, I will repeat it
here. I would love if the first 3 points of the add on could be used WITHOUT the
QCGroupedFormRenderer. Or at least a class that doesn't imply many changes. In other
words...to plug that nice behavior with the default rendered class: MATableRenderer.
would that be possible?
Thanks in advance,
If people have questions about QC-Magritte, please do not hesitate to ask them. I will
try to respond them fast and I will be available on Skype and Google Hangouts.
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
3:01 p.m.
On Wed, Dec 11, 2013 at 10:38 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi Mariano,
Yes, I will move those to QC-Magritte-Ajax (done). QC-Magritte-Other is a
collection of all the things that do not have a good place yet.
Cool, thanks!
One thing in trying do separate them into groups: a
table can only
re-render a single row, or an entire table. So you will have to create
subtables, or some other structure to allow that in Ajax.
Good point. Well...did you remember I told you I have my own subclass of
MATableRenderer? Well...my subclass DOES NOT user HTML tables. Instead, it
uses DIVs (actually Bootstrap tbsColumns, and tbsRows, etc... (I can share
this render if someone is interested) So in such a case I would not have
this problem right?
So probably I can extract such behavior from QCGroupedFormRenderer. Could
you tell me which is the key part to extract?
Thanks Diego,
And I see I missed a question. Yes, QC-Magritte-Ajax
depends on JQuery.
Cheers,
Diego
On Dec 11, 2013, at 2:07 PM, Mariano Martinez Peck wrote:
On Wed, Dec 11, 2013 at 9:25 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
--
Mariano
http://marianopeck.wordpress.com
Hi Mariano,
Ok, I have extracted the functionality you need in QC-Magritte-Ajax. It
contains a custom renderer to override the table renderer
(QCAjaxTableRenderer). Note that it re-renders the entire table on each
change … so it does not need groups. Unfortunately it does not keep the
focus, this is the only thing that bugs me, and rendering more of the page,
gives a bigger chance of giving the user some annoyance over this.
The package QC-Magritte-Ajax should work stand alone, I did not test this
yet.
Hi Diego, thanks for doing that! A quick tests shows me that it works! The
only small detail is that
QCAjaxMemento #procesHiddenFor: aDescription value: anObject sends
#hiddenValues to the description and #readUsing: sends #isWrapped. We
don't have either of them.
So I think we either move those 2 to QC-Magritte-Ajax or we put a
dependency to QC-Magritte-Other (and hence also QC-Magritte-Core). Maybe
the first option is easier.
In my particular use-case, I usually have many combos lists in which the
"options and values" comes from a DB query. Even if I do have caches etc I
would try to avoid doing such a queries each time a field is modified. So I
will see if I can adapt QCAjaxTableRenderer to perform the ajax only for
groups (as it was the previous render). I think that having ALSO such
feature also in QCAjaxTableRenderer would be awesome. Then we can have
simple flags to update all fields or update only by groups :)
Thanks Diego, it is good to see Magritte-Seaside moving forward!
Cheers,
Diego
On Dec 10, 2013, at 6:37 PM, Mariano Martinez Peck wrote:
On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Hi all,
As you probably all know I have made a library (QC Magritte) that is
build on top of Magritte. I think it contains a lot of good add ons, maybe
not structured enough. I am trying to clean this code up, so it can be used
easily by all. At this point I want to move 2 things to Magritte. One as a
change, and one as an add-on:
Change:
I would like to modify the basic MAContainerComponent to cache the
description and pre-process this with the description builders. I believe
this is a missing hook in Magritte. It is easy to add, and you do not
notice it, if you do not use it. Also it applies to all platforms, not just
to Seaside, so if you think this is a good idea, I will also modify the
glamour container. The following problems can be solved using builders:
- separating display from the model. Now you have to set your
custom component classes in the model. It is much more elegant to do this
from the display side. To add a builder it can set the component class for
each type of description (using visitors), for the application you want to
show.
- adding security. When you pre process the description before
showing it, you can set fields to readonly, or remove them entirely from
the description if the user is not allowed to see those properties.
Add-On:
I would ilke to add a package to Magritte3-AddOns called Magritte-Ajax.
In this add-on I will put the things that allow Ajax rendering of the
components. Of course this is on top of seaside and only valid for seaside,
but that is why I think it should be an add-on and not in the core. This
would be:
- The AjaxMemento. (QCAjaxMemento)
- the extension methods for Ajax rendering.
- the extension methods for the added Ajax properties.
All these for sure!
- A renderer, that renders the component,
using Ajax.
(QCGroupedFormRenderer)
Please let me know if you think this is a good idea. If you know a
better place to do these things, or to put the code, let me know.
Hi Diego,
First, thanks for pushing this stuff. I also have many extensions I did
myself to Magritte and so far I have them as subclasses or extension
methods etc. I need to clean them up before asking if they are useful. I
will send a separate mail for that.
For this particular email, I think that what you suggest makes sense.
Magritte-Ajax will depend on JQuery right?
I should have answered this email instead of the other one...anyway, I
will repeat it here. I would love if the first 3 points of the add on could
be used WITHOUT the QCGroupedFormRenderer. Or at least a class that
doesn't imply many changes. In other words...to plug that nice behavior
with the default rendered class: MATableRenderer.
would that be possible?
Thanks in advance,
If people have questions about QC-Magritte,
please do not hesitate to
ask them. I will try to respond them fast and I will be available on Skype
and Google Hangouts.
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
6:29 p.m.
OK....I started to merge QCGroupedFormRenderer with my own table. So far so
good.
I have one question. I am trying to put 3 descriptions into the same group.
For some reasons I cannot discover, 2 out of 3, gets re-render. One of them
isn't (its description method is not even called). And as far as I can see
it looks the same as one of the other descriptions that does get call and
re-render.
Any bell?
Thanks!
On Wed, Dec 11, 2013 at 11:01 AM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
On Wed, Dec 11, 2013 at 10:38 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
--
Mariano
http://marianopeck.wordpress.com
Hi Mariano,
Yes, I will move those to QC-Magritte-Ajax (done). QC-Magritte-Other is a
collection of all the things that do not have a good place yet.
Cool, thanks!
One thing in trying do separate them into groups:
a table can only
re-render a single row, or an entire table. So you will have to create
subtables, or some other structure to allow that in Ajax.
Good point. Well...did you remember I told you I have my own subclass of
MATableRenderer? Well...my subclass DOES NOT user HTML tables. Instead, it
uses DIVs (actually Bootstrap tbsColumns, and tbsRows, etc... (I can share
this render if someone is interested) So in such a case I would not have
this problem right?
So probably I can extract such behavior from QCGroupedFormRenderer. Could
you tell me which is the key part to extract?
Thanks Diego,
And I see I missed a question. Yes,
QC-Magritte-Ajax depends on JQuery.
Cheers,
Diego
On Dec 11, 2013, at 2:07 PM, Mariano Martinez Peck wrote:
On Wed, Dec 11, 2013 at 9:25 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
--
Mariano
http://marianopeck.wordpress.com
Hi Mariano,
Ok, I have extracted the functionality you need in QC-Magritte-Ajax. It
contains a custom renderer to override the table renderer
(QCAjaxTableRenderer). Note that it re-renders the entire table on each
change … so it does not need groups. Unfortunately it does not keep the
focus, this is the only thing that bugs me, and rendering more of the page,
gives a bigger chance of giving the user some annoyance over this.
The package QC-Magritte-Ajax should work stand alone, I did not test
this yet.
Hi Diego, thanks for doing that! A quick tests shows me that it works!
The only small detail is that
QCAjaxMemento #procesHiddenFor: aDescription value: anObject sends
#hiddenValues to the description and #readUsing: sends #isWrapped. We
don't have either of them.
So I think we either move those 2 to QC-Magritte-Ajax or we put a
dependency to QC-Magritte-Other (and hence also QC-Magritte-Core). Maybe
the first option is easier.
In my particular use-case, I usually have many combos lists in which the
"options and values" comes from a DB query. Even if I do have caches etc I
would try to avoid doing such a queries each time a field is modified. So I
will see if I can adapt QCAjaxTableRenderer to perform the ajax only for
groups (as it was the previous render). I think that having ALSO such
feature also in QCAjaxTableRenderer would be awesome. Then we can have
simple flags to update all fields or update only by groups :)
Thanks Diego, it is good to see Magritte-Seaside moving forward!
Cheers,
Diego
On Dec 10, 2013, at 6:37 PM, Mariano Martinez Peck wrote:
On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Hi all,
As you probably all know I have made a library (QC Magritte) that is
build on top of Magritte. I think it contains a lot of good add ons, maybe
not structured enough. I am trying to clean this code up, so it can be used
easily by all. At this point I want to move 2 things to Magritte. One as a
change, and one as an add-on:
Change:
I would like to modify the basic MAContainerComponent to cache the
description and pre-process this with the description builders. I believe
this is a missing hook in Magritte. It is easy to add, and you do not
notice it, if you do not use it. Also it applies to all platforms, not just
to Seaside, so if you think this is a good idea, I will also modify the
glamour container. The following problems can be solved using builders:
- separating display from the model. Now you have to set your
custom component classes in the model. It is much more elegant to do this
from the display side. To add a builder it can set the component class for
each type of description (using visitors), for the application you want to
show.
- adding security. When you pre process the description before
showing it, you can set fields to readonly, or remove them entirely from
the description if the user is not allowed to see those properties.
Add-On:
I would ilke to add a package to Magritte3-AddOns called Magritte-Ajax.
In this add-on I will put the things that allow Ajax rendering of the
components. Of course this is on top of seaside and only valid for seaside,
but that is why I think it should be an add-on and not in the core. This
would be:
- The AjaxMemento. (QCAjaxMemento)
- the extension methods for Ajax rendering.
- the extension methods for the added Ajax properties.
All these for sure!
- A renderer, that renders the component,
using Ajax.
(QCGroupedFormRenderer)
Please let me know if you think this is a good idea. If you know a
better place to do these things, or to put the code, let me know.
Hi Diego,
First, thanks for pushing this stuff. I also have many extensions I did
myself to Magritte and so far I have them as subclasses or extension
methods etc. I need to clean them up before asking if they are useful. I
will send a separate mail for that.
For this particular email, I think that what you suggest makes sense.
Magritte-Ajax will depend on JQuery right?
I should have answered this email instead of the other one...anyway, I
will repeat it here. I would love if the first 3 points of the add on could
be used WITHOUT the QCGroupedFormRenderer. Or at least a class that
doesn't imply many changes. In other words...to plug that nice behavior
with the default rendered class: MATableRenderer.
would that be possible?
Thanks in advance,
If people have questions about QC-Magritte,
please do not hesitate to
ask them. I will try to respond them fast and I will be available on Skype
and Google Hangouts.
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
7:19 p.m.
Ok, the problem was that
renderEditorOn: html ajaxScript: aScript
(self magritteDescription isGrouped and: [ self magritteDescription
groupBy canRead: self value ])
ifTrue: [ self renderEditorForGroupedOn: html ]
ifFalse: [ self renderEditorForUngroupedOn: html ajaxScript: aScript ]
MASingleOptionDescription implements #isGrouped answering:
isGrouped ^ self groupBy notNil
and of course, in my description groupBy was giving nil....
mmmm I have never ever used #groupBy: so I don't know...
thoughts?
On Wed, Dec 11, 2013 at 2:29 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
OK....I started to merge QCGroupedFormRenderer with my
own table. So far
so good.
I have one question. I am trying to put 3 descriptions into the same
group. For some reasons I cannot discover, 2 out of 3, gets re-render. One
of them isn't (its description method is not even called). And as far as I
can see it looks the same as one of the other descriptions that does get
call and re-render.
Any bell?
Thanks!
On Wed, Dec 11, 2013 at 11:01 AM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
--
Mariano
http://marianopeck.wordpress.com
On Wed, Dec 11, 2013 at 10:38 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
--
Mariano
http://marianopeck.wordpress.com
Hi Mariano,
Yes, I will move those to QC-Magritte-Ajax (done). QC-Magritte-Other
is a collection of all the things that do not have a good place yet.
Cool, thanks!
One thing in trying do separate them into
groups: a table can only
re-render a single row, or an entire table. So you will have to create
subtables, or some other structure to allow that in Ajax.
Good point. Well...did you remember I told you I have my own subclass of
MATableRenderer? Well...my subclass DOES NOT user HTML tables. Instead, it
uses DIVs (actually Bootstrap tbsColumns, and tbsRows, etc... (I can share
this render if someone is interested) So in such a case I would not have
this problem right?
So probably I can extract such behavior from QCGroupedFormRenderer. Could
you tell me which is the key part to extract?
Thanks Diego,
And I see I missed a question. Yes,
QC-Magritte-Ajax depends on JQuery.
Cheers,
Diego
On Dec 11, 2013, at 2:07 PM, Mariano Martinez Peck wrote:
On Wed, Dec 11, 2013 at 9:25 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
--
Mariano
http://marianopeck.wordpress.com
Hi Mariano,
Ok, I have extracted the functionality you need in QC-Magritte-Ajax. It
contains a custom renderer to override the table renderer
(QCAjaxTableRenderer). Note that it re-renders the entire table on each
change … so it does not need groups. Unfortunately it does not keep the
focus, this is the only thing that bugs me, and rendering more of the page,
gives a bigger chance of giving the user some annoyance over this.
The package QC-Magritte-Ajax should work stand alone, I did not test
this yet.
Hi Diego, thanks for doing that! A quick tests shows me that it works!
The only small detail is that
QCAjaxMemento #procesHiddenFor: aDescription value: anObject sends
#hiddenValues to the description and #readUsing: sends #isWrapped. We
don't have either of them.
So I think we either move those 2 to QC-Magritte-Ajax or we put a
dependency to QC-Magritte-Other (and hence also QC-Magritte-Core). Maybe
the first option is easier.
In my particular use-case, I usually have many combos lists in which the
"options and values" comes from a DB query. Even if I do have caches etc I
would try to avoid doing such a queries each time a field is modified. So I
will see if I can adapt QCAjaxTableRenderer to perform the ajax only for
groups (as it was the previous render). I think that having ALSO such
feature also in QCAjaxTableRenderer would be awesome. Then we can have
simple flags to update all fields or update only by groups :)
Thanks Diego, it is good to see Magritte-Seaside moving forward!
Cheers,
Diego
On Dec 10, 2013, at 6:37 PM, Mariano Martinez Peck wrote:
On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
> Hi all,
>
> As you probably all know I have made a library (QC Magritte) that is
> build on top of Magritte. I think it contains a lot of good add ons, maybe
> not structured enough. I am trying to clean this code up, so it can be used
> easily by all. At this point I want to move 2 things to Magritte. One as a
> change, and one as an add-on:
>
> Change:
> I would like to modify the basic MAContainerComponent to cache the
> description and pre-process this with the description builders. I believe
> this is a missing hook in Magritte. It is easy to add, and you do not
> notice it, if you do not use it. Also it applies to all platforms, not just
> to Seaside, so if you think this is a good idea, I will also modify the
> glamour container. The following problems can be solved using builders:
> - separating display from the model. Now you have to set your
> custom component classes in the model. It is much more elegant to do this
> from the display side. To add a builder it can set the component class for
> each type of description (using visitors), for the application you want to
> show.
> - adding security. When you pre process the description before
> showing it, you can set fields to readonly, or remove them entirely from
> the description if the user is not allowed to see those properties.
>
> Add-On:
> I would ilke to add a package to Magritte3-AddOns called
> Magritte-Ajax. In this add-on I will put the things that allow Ajax
> rendering of the components. Of course this is on top of seaside and only
> valid for seaside, but that is why I think it should be an add-on and not
> in the core. This would be:
> - The AjaxMemento. (QCAjaxMemento)
> - the extension methods for Ajax rendering.
> - the extension methods for the added Ajax properties.
>
All these for sure!
> - A renderer, that renders the component, using Ajax.
> (QCGroupedFormRenderer)
>
> Please let me know if you think this is a good idea. If you know a
> better place to do these things, or to put the code, let me know.
>
>
Hi Diego,
First, thanks for pushing this stuff. I also have many extensions I did
myself to Magritte and so far I have them as subclasses or extension
methods etc. I need to clean them up before asking if they are useful. I
will send a separate mail for that.
For this particular email, I think that what you suggest makes sense.
Magritte-Ajax will depend on JQuery right?
I should have answered this email instead of the other one...anyway, I
will repeat it here. I would love if the first 3 points of the add on could
be used WITHOUT the QCGroupedFormRenderer. Or at least a class that
doesn't imply many changes. In other words...to plug that nice behavior
with the default rendered class: MATableRenderer.
would that be possible?
Thanks in advance,
> If people have questions about QC-Magritte, please do not hesitate to
> ask them. I will try to respond them fast and I will be available on Skype
> and Google Hangouts.
>
> Cheers,
> Diego
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
7:22 p.m.
Forget what I have just sent....it is nonesense
On Wed, Dec 11, 2013 at 3:19 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
Ok, the problem was that
renderEditorOn: html ajaxScript: aScript
(self magritteDescription isGrouped and: [ self magritteDescription
groupBy canRead: self value ])
ifTrue: [ self renderEditorForGroupedOn: html ]
ifFalse: [ self renderEditorForUngroupedOn: html ajaxScript: aScript ]
MASingleOptionDescription implements #isGrouped answering:
isGrouped ^ self groupBy notNil
and of course, in my description groupBy was giving nil....
mmmm I have never ever used #groupBy: so I don't know...
thoughts?
On Wed, Dec 11, 2013 at 2:29 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
--
Mariano
http://marianopeck.wordpress.com
OK....I started to merge QCGroupedFormRenderer
with my own table. So far
so good.
I have one question. I am trying to put 3 descriptions into the same
group. For some reasons I cannot discover, 2 out of 3, gets re-render. One
of them isn't (its description method is not even called). And as far as I
can see it looks the same as one of the other descriptions that does get
call and re-render.
Any bell?
Thanks!
On Wed, Dec 11, 2013 at 11:01 AM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
--
Mariano
http://marianopeck.wordpress.com
On Wed, Dec 11, 2013 at 10:38 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
--
Mariano
http://marianopeck.wordpress.com
Hi Mariano,
Yes, I will move those to QC-Magritte-Ajax (done). QC-Magritte-Other
is a collection of all the things that do not have a good place yet.
Cool, thanks!
One thing in trying do separate them into
groups: a table can only
re-render a single row, or an entire table. So you will have to create
subtables, or some other structure to allow that in Ajax.
Good point. Well...did you remember I told you I have my own subclass of
MATableRenderer? Well...my subclass DOES NOT user HTML tables. Instead, it
uses DIVs (actually Bootstrap tbsColumns, and tbsRows, etc... (I can share
this render if someone is interested) So in such a case I would not have
this problem right?
So probably I can extract such behavior from QCGroupedFormRenderer.
Could you tell me which is the key part to extract?
Thanks Diego,
And I see I missed a question. Yes,
QC-Magritte-Ajax depends on JQuery.
Cheers,
Diego
On Dec 11, 2013, at 2:07 PM, Mariano Martinez Peck wrote:
On Wed, Dec 11, 2013 at 9:25 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
> Hi Mariano,
>
> Ok, I have extracted the functionality you need in QC-Magritte-Ajax.
> It contains a custom renderer to override the table renderer
> (QCAjaxTableRenderer). Note that it re-renders the entire table on each
> change … so it does not need groups. Unfortunately it does not keep the
> focus, this is the only thing that bugs me, and rendering more of the page,
> gives a bigger chance of giving the user some annoyance over this.
>
> The package QC-Magritte-Ajax should work stand alone, I did not test
> this yet.
>
>
Hi Diego, thanks for doing that! A quick tests shows me that it works!
The only small detail is that
QCAjaxMemento #procesHiddenFor: aDescription value: anObject sends
#hiddenValues to the description and #readUsing: sends #isWrapped. We
don't have either of them.
So I think we either move those 2 to QC-Magritte-Ajax or we put a
dependency to QC-Magritte-Other (and hence also QC-Magritte-Core). Maybe
the first option is easier.
In my particular use-case, I usually have many combos lists in which
the "options and values" comes from a DB query. Even if I do have caches
etc I would try to avoid doing such a queries each time a field is
modified. So I will see if I can adapt QCAjaxTableRenderer to perform the
ajax only for groups (as it was the previous render). I think that having
ALSO such feature also in QCAjaxTableRenderer would be awesome. Then we can
have simple flags to update all fields or update only by groups :)
Thanks Diego, it is good to see Magritte-Seaside moving forward!
> Cheers,
> Diego
>
> On Dec 10, 2013, at 6:37 PM, Mariano Martinez Peck wrote:
>
>
>
>
> On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
>
>> Hi all,
>>
>> As you probably all know I have made a library (QC Magritte) that is
>> build on top of Magritte. I think it contains a lot of good add ons, maybe
>> not structured enough. I am trying to clean this code up, so it can be used
>> easily by all. At this point I want to move 2 things to Magritte. One as a
>> change, and one as an add-on:
>>
>> Change:
>> I would like to modify the basic MAContainerComponent to cache the
>> description and pre-process this with the description builders. I believe
>> this is a missing hook in Magritte. It is easy to add, and you do not
>> notice it, if you do not use it. Also it applies to all platforms, not just
>> to Seaside, so if you think this is a good idea, I will also modify the
>> glamour container. The following problems can be solved using builders:
>> - separating display from the model. Now you have to set your
>> custom component classes in the model. It is much more elegant to do this
>> from the display side. To add a builder it can set the component class for
>> each type of description (using visitors), for the application you want to
>> show.
>> - adding security. When you pre process the description
>> before showing it, you can set fields to readonly, or remove them entirely
>> from the description if the user is not allowed to see those properties.
>>
>> Add-On:
>> I would ilke to add a package to Magritte3-AddOns called
>> Magritte-Ajax. In this add-on I will put the things that allow Ajax
>> rendering of the components. Of course this is on top of seaside and only
>> valid for seaside, but that is why I think it should be an add-on and not
>> in the core. This would be:
>> - The AjaxMemento. (QCAjaxMemento)
>> - the extension methods for Ajax rendering.
>> - the extension methods for the added Ajax properties.
>>
>
> All these for sure!
>
>
>> - A renderer, that renders the component, using Ajax.
>> (QCGroupedFormRenderer)
>>
>> Please let me know if you think this is a good idea. If you know a
>> better place to do these things, or to put the code, let me know.
>>
>>
> Hi Diego,
>
> First, thanks for pushing this stuff. I also have many extensions I
> did myself to Magritte and so far I have them as subclasses or extension
> methods etc. I need to clean them up before asking if they are useful. I
> will send a separate mail for that.
>
> For this particular email, I think that what you suggest makes sense.
> Magritte-Ajax will depend on JQuery right?
>
> I should have answered this email instead of the other one...anyway, I
> will repeat it here. I would love if the first 3 points of the add on could
> be used WITHOUT the QCGroupedFormRenderer. Or at least a class that
> doesn't imply many changes. In other words...to plug that nice behavior
> with the default rendered class: MATableRenderer.
>
> would that be possible?
>
> Thanks in advance,
>
>
>
>
>
>> If people have questions about QC-Magritte, please do not hesitate to
>> ask them. I will try to respond them fast and I will be available on Skype
>> and Google Hangouts.
>>
>> Cheers,
>> Diego
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
9:09 p.m.
Hi Diego,
I have a question. I think I reached a limitation. From what I understand,
you put a div for the group and you use that ID for the AJAX. Since you use
a close priotity between each description that belongs to the same group,
then it is not a problem...all labels/controls end up inside that DIV for
the group with the defined ID for the AJAX.
I wonder....is there a way/workaround if I want to have the descriptions
belonging to a group separated? I know... probably I should use a better
name since Group in magritte is for displaying them together etc. In my
case is about "refresh connectivity" or "value dependency" or
something
like that, but not necessary they should be displayed one after the other
one.
Is there any workaround? For example, what if I do something similar to
what you did in QCAjaxTableRenderer but instead of rendering the whole
container, I take 'containerDescription' instVar, ask the descriptions for
the group XXX and send a an AJAX for them?
Thoughts?
On Wed, Dec 11, 2013 at 3:22 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
Forget what I have just sent....it is nonesense
On Wed, Dec 11, 2013 at 3:19 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
--
Mariano
http://marianopeck.wordpress.com
Ok, the problem was that
renderEditorOn: html ajaxScript: aScript
(self magritteDescription isGrouped and: [ self magritteDescription
groupBy canRead: self value ])
ifTrue: [ self renderEditorForGroupedOn: html ]
ifFalse: [ self renderEditorForUngroupedOn: html ajaxScript: aScript ]
MASingleOptionDescription implements #isGrouped answering:
isGrouped ^ self groupBy notNil
and of course, in my description groupBy was giving nil....
mmmm I have never ever used #groupBy: so I don't know...
thoughts?
On Wed, Dec 11, 2013 at 2:29 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
--
Mariano
http://marianopeck.wordpress.com
OK....I started to merge QCGroupedFormRenderer
with my own table. So
far so good.
I have one question. I am trying to put 3 descriptions into the same
group. For some reasons I cannot discover, 2 out of 3, gets re-render. One
of them isn't (its description method is not even called). And as far as I
can see it looks the same as one of the other descriptions that does get
call and re-render.
Any bell?
Thanks!
On Wed, Dec 11, 2013 at 11:01 AM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
--
Mariano
http://marianopeck.wordpress.com
On Wed, Dec 11, 2013 at 10:38 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
> Hi Mariano,
>
> Yes, I will move those to QC-Magritte-Ajax (done). QC-Magritte-Other
> is a collection of all the things that do not have a good place yet.
>
>
Cool, thanks!
> One thing in trying do separate them into groups: a table can only
> re-render a single row, or an entire table. So you will have to create
> subtables, or some other structure to allow that in Ajax.
>
>
Good point. Well...did you remember I told you I have my own subclass
of MATableRenderer? Well...my subclass DOES NOT user HTML tables. Instead,
it uses DIVs (actually Bootstrap tbsColumns, and tbsRows, etc... (I can
share this render if someone is interested) So in such a case I would not
have this problem right?
So probably I can extract such behavior from QCGroupedFormRenderer.
Could you tell me which is the key part to extract?
Thanks Diego,
> And I see I missed a question. Yes, QC-Magritte-Ajax depends on JQuery.
>
> Cheers,
> Diego
>
> On Dec 11, 2013, at 2:07 PM, Mariano Martinez Peck wrote:
>
>
>
>
> On Wed, Dec 11, 2013 at 9:25 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
>
>> Hi Mariano,
>>
>> Ok, I have extracted the functionality you need in QC-Magritte-Ajax.
>> It contains a custom renderer to override the table renderer
>> (QCAjaxTableRenderer). Note that it re-renders the entire table on each
>> change … so it does not need groups. Unfortunately it does not keep the
>> focus, this is the only thing that bugs me, and rendering more of the page,
>> gives a bigger chance of giving the user some annoyance over this.
>>
>> The package QC-Magritte-Ajax should work stand alone, I did not test
>> this yet.
>>
>>
> Hi Diego, thanks for doing that! A quick tests shows me that it works!
> The only small detail is that
>
> QCAjaxMemento #procesHiddenFor: aDescription value: anObject sends
> #hiddenValues to the description and #readUsing: sends #isWrapped. We
> don't have either of them.
> So I think we either move those 2 to QC-Magritte-Ajax or we put a
> dependency to QC-Magritte-Other (and hence also QC-Magritte-Core). Maybe
> the first option is easier.
>
> In my particular use-case, I usually have many combos lists in which
> the "options and values" comes from a DB query. Even if I do have caches
> etc I would try to avoid doing such a queries each time a field is
> modified. So I will see if I can adapt QCAjaxTableRenderer to perform the
> ajax only for groups (as it was the previous render). I think that having
> ALSO such feature also in QCAjaxTableRenderer would be awesome. Then we can
> have simple flags to update all fields or update only by groups :)
>
> Thanks Diego, it is good to see Magritte-Seaside moving forward!
>
>
>
>
>> Cheers,
>> Diego
>>
>> On Dec 10, 2013, at 6:37 PM, Mariano Martinez Peck wrote:
>>
>>
>>
>>
>> On Tue, Dec 10, 2013 at 7:50 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
>>
>>> Hi all,
>>>
>>> As you probably all know I have made a library (QC Magritte) that is
>>> build on top of Magritte. I think it contains a lot of good add ons, maybe
>>> not structured enough. I am trying to clean this code up, so it can be used
>>> easily by all. At this point I want to move 2 things to Magritte. One as a
>>> change, and one as an add-on:
>>>
>>> Change:
>>> I would like to modify the basic MAContainerComponent to cache the
>>> description and pre-process this with the description builders. I believe
>>> this is a missing hook in Magritte. It is easy to add, and you do not
>>> notice it, if you do not use it. Also it applies to all platforms, not just
>>> to Seaside, so if you think this is a good idea, I will also modify the
>>> glamour container. The following problems can be solved using builders:
>>> - separating display from the model. Now you have to set
>>> your custom component classes in the model. It is much more elegant to do
>>> this from the display side. To add a builder it can set the component class
>>> for each type of description (using visitors), for the application you want
>>> to show.
>>> - adding security. When you pre process the description
>>> before showing it, you can set fields to readonly, or remove them entirely
>>> from the description if the user is not allowed to see those properties.
>>>
>>> Add-On:
>>> I would ilke to add a package to Magritte3-AddOns called
>>> Magritte-Ajax. In this add-on I will put the things that allow Ajax
>>> rendering of the components. Of course this is on top of seaside and only
>>> valid for seaside, but that is why I think it should be an add-on and not
>>> in the core. This would be:
>>> - The AjaxMemento. (QCAjaxMemento)
>>> - the extension methods for Ajax rendering.
>>> - the extension methods for the added Ajax properties.
>>>
>>
>> All these for sure!
>>
>>
>>> - A renderer, that renders the component, using Ajax.
>>> (QCGroupedFormRenderer)
>>>
>>> Please let me know if you think this is a good idea. If you know a
>>> better place to do these things, or to put the code, let me know.
>>>
>>>
>> Hi Diego,
>>
>> First, thanks for pushing this stuff. I also have many extensions I
>> did myself to Magritte and so far I have them as subclasses or extension
>> methods etc. I need to clean them up before asking if they are useful. I
>> will send a separate mail for that.
>>
>> For this particular email, I think that what you suggest makes sense.
>> Magritte-Ajax will depend on JQuery right?
>>
>> I should have answered this email instead of the other one...anyway,
>> I will repeat it here. I would love if the first 3 points of the add on
>> could be used WITHOUT the QCGroupedFormRenderer. Or at least a class that
>> doesn't imply many changes. In other words...to plug that nice behavior
>> with the default rendered class: MATableRenderer.
>>
>> would that be possible?
>>
>> Thanks in advance,
>>
>>
>>
>>
>>
>>> If people have questions about QC-Magritte, please do not hesitate
>>> to ask them. I will try to respond them fast and I will be available on
>>> Skype and Google Hangouts.
>>>
>>> Cheers,
>>> Diego
>>> _______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>>
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
--
Mariano
http://marianopeck.wordpress.com
--
Mariano
http://marianopeck.wordpress.com
9:28 p.m.
On 11 dec. 2013, at 21:09, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote:
I have a question. I think I reached a limitation.
From what I understand, you put a div for the group and you use that ID for the AJAX.
Since you use a close priotity between each description that belongs to the same group,
then it is not a problem...all labels/controls end up inside that DIV for the group with
the defined ID for the AJAX.
I wonder....is there a way/workaround if I want to have the descriptions belonging to a
group separated? I know... probably I should use a better name since Group in magritte is
for displaying them together etc. In my case is about "refresh connectivity" or
"value dependency" or something like that, but not necessary they should be
displayed one after the other one.
You can of course make the update much more complex, but we found (in what we build)
simply refreshing either the whole page or a common parent sufficiently performant. If you
connect arbitrary (nested) elements you need to avoid update cycles.
Stephan
10:22 p.m.
On Wed, Dec 11, 2013 at 5:28 PM, Stephan Eggermont <stephan(a)stack.nl> wrote:
On 11 dec. 2013, at 21:09, Mariano Martinez Peck
<marianopeck(a)gmail.com>
wrote:
Ok, I understand. What I need is:
1) To not re-render all fields (I have many forms where I have many lists
that are queried from a DB) for every single field modification.
2) I don't want to have to display some fields together in order to have
them been re-rendered when one of them has been modified.
3) I am not obligued to use #group: I can use something different, like
#dependentsGroups or something like that
Any hint on how to implement that adapting your very cool stuff will be
very much appreciated!
I have a question. I think I reached a
limitation. From what I
understand, you put a div for the group and you use that ID
for the AJAX.
Since you use a close priotity between each description that belongs to the
same group, then it is not a problem...all labels/controls end up inside
that DIV for the group with the defined ID for the AJAX.
I wonder....is there a way/workaround if I want
to have the descriptions
belonging to a group separated? I know... probably I
should use a better
name since Group in magritte is for displaying them together etc. In my
case is about "refresh connectivity" or "value dependency" or
something
like that, but not necessary they should be displayed one after the other
one.
You can of course make the update much more complex, but we found (in what
we build) simply refreshing either the whole page or a common parent
sufficiently performant. If you connect arbitrary (nested) elements you
need to avoid update cycles.
Stephan
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
13 Dec
13 Dec
4:59 p.m.
On 11 dec. 2013, at 21:09, Mariano Martinez Peck
<marianopeck(a)gmail.com> wrote:
Ok, I understand. What I need is:
1) To not re-render all fields (I have many forms where I have many lists that are
queried from a DB) for every single field modification.
Yes, that should not be the problem. That was what the rendering in groups was for. The
method that creates the script does it on a single id, and creates and updater for this
part of the page only.
2) I don't want to have to display some fields
together in order to have them been re-rendered when one of them has been modified.
That implies adding multiple updates, so multiple scripts to the same input. So instead of
adding a "script: aScript" parameter, we probably should have a variant that
adds a "scripts: aCollection" parameter. I am not sure how the implementation
should look like exactly. You can try simply adding all scripts. Of course: beware of
loops, because otherwise the loading will never stop.
3) I am not obligued to use #group: I can use
something different, like #dependentsGroups or something like that
Point taken. I misused group here. I probably should have introduced another term. Do you
have a good suggestion? I do not think we should couple this to group.
Diego
P.S. If added you as contributor to QCMagritte
5:30 p.m.
On Fri, Dec 13, 2013 at 12:59 PM, Diego Lont <diego.lont(a)delware.nl> wrote:
OK
> 3) I am not obligued to use #group: I can use something different, like
> #dependentsGroups or something like that
> Point taken. I misused group here. I probably should have introduced
> another term. Do you have a good suggestion? I do not think we should
> couple this to group.
#dependenciesGroup: ?
#notificationGroup:
#updaterGroup:
same of above but using the word "set" instead of group (to avoid any
confusion with Magritte groups). Like "dependenciesSet"
> Diego
>
> P.S. If added you as contributor to QCMagritte
Thanks!
On 11 dec. 2013, at 21:09, Mariano Martinez Peck
<marianopeck(a)gmail.com
1) To not re-render all fields (I have many forms where I have many lists
that are queried from a DB) for every single field modification.
Yes, that should not be the problem. That was what the rendering in groups
was for. The method that creates the script does it on a single id, and
creates and updater for this part of the page only.
Yes, I saw that. You either create the script for the whole form or for the
group div.
wrote:
Ok, I understand. What I need is:
2) I don't want to have to display some fields together in order to have
them been re-rendered when one of them has been modified.
That implies adding multiple updates, so multiple scripts to the same
input.
Yes. Each element of the group has multiple scripts (one for each other of
the group), right?
So instead of adding a "script: aScript"
parameter, we probably should
have a variant that adds a "scripts: aCollection" parameter. I am not sure
how the implementation should look like exactly. You can try simply adding
all scripts.
What if:
- We store the container (as you did with the AjaxTable..)
- to the container we ask the "dependencyGroups" (I pick this name for this
mail).
- We create a script for each element of each dependencyGroup.
- To each element of each dependencyGroup we set all the scripts of that
group.
Sounds ok but no idea how to implement it heheheh. But the flexibility is
huge. You decouple from #group, you decouple from the fact of having to
display dependent fields one below another one...
Of course: beware of loops, because otherwise the loading will never stop.
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
6:46 p.m.
2) I don't
want to have to display some fields together in order to have them been re-rendered when
one of them has been modified.
That implies adding multiple updates, so multiple scripts to the same input.
Yes. Each element of the group has multiple scripts (one for each other of the group),
right? So instead of adding a "script: aScript"
parameter, we probably should have a variant that adds a "scripts: aCollection"
parameter. I am not sure how the implementation should look like exactly. You can try
simply adding all scripts.
What if:
- We store the container (as you did with the AjaxTable..)
- to the container we ask the "dependencyGroups" (I pick this name for this
mail).
- We create a script for each element of each dependencyGroup.
- To each element of each dependencyGroup we set all the scripts of that group.
I do not think we should keep the implementation symmetric. As this implementation will
create rendering loops for sure.
In your example: state should be re-rendered if country is changed but not the other way
around. But when I think further on it: we can already determine what fields should be
re-rendered. A description is based on several other descriptions. (influences and dynamic
options). As long as this is a tree the implementation should be easy enough. You process
the description twice:
First pass:
Each description that is influenced by one or more other values gets an id.*
Each description that influences one or more other values gets a list of description
that it influences.*
* Here we can use that a description is the same if type and accessor are the same. I used
this as well in the influences.
Second pass:
Render the descriptions and add for all influences a script to update the influenced
values.**
** Of course this will fail if we have a loop. I.e.: First name, Sir name, Full name
--> all three are connected and then we have to think something how to avoid a
re-render loop.
I will try to find time to make a basic implementation on Monday, but I do not promise
anything. It is nice that other people try to use my stuff, so we can improve on it.
3) I am not obligued to use #group: I can use
something different, like #dependentsGroups or something like that
Point taken. I misused group here. I probably should have introduced another term. Do you
have a good suggestion? I do not think we should couple this to group.
#dependenciesGroup: ?
#notificationGroup:
#updaterGroup:
same of above but using the word "set" instead of group (to avoid any confusion
with Magritte groups). Like "dependenciesSet"
7:45 p.m.
On Fri, Dec 13, 2013 at 2:46 PM, Diego Lont <diego.lont(a)delware.nl> wrote:
but what would you put in each description otherwise? #influencedBy: ,
#influencesTo: ?
Cheers,
2) I don't want to have to display some fields
together in order to have
OK
them been re-rendered when one of them has been
modified.
That implies adding multiple updates, so multiple scripts to the same
input.
Yes. Each element of the group has multiple scripts (one for each other of
the group), right?
Not always ...
So instead of adding a "script: aScript" parameter, we probably should
have a variant that adds a "scripts:
aCollection" parameter. I am not sure
how the implementation should look like exactly. You can try simply adding
all scripts.
What if:
- We store the container (as you did with the AjaxTable..)
- to the container we ask the "dependencyGroups" (I pick this name for
this mail).
- We create a script for each element of each dependencyGroup.
- To each element of each dependencyGroup we set all the scripts of that
group.
I do not think we should keep the implementation symmetric. As this
implementation will create rendering loops for sure.
In your example: state should be re-rendered if
country is changed but not
the other way around.
Actually, I don't really care if the country is re-render. I mean...it's
not thaaaaaat bad. At least we are not refreshing the whole form. It's just
a few fields.
I think the easiest path is that all elements of the group is re-rendered.
Future usecase could allow what you suggest here (like country not updating
if I change state), but that could be a second step of improvement if
complicates stuff...
But when I think further on it: we can already
determine what fields
should be re-rendered. A description is based on several other
descriptions. (influences and dynamic options). As long as this is a tree
the implementation should be easy enough. You process the description twice:
First pass:
Each description that is influenced by one or more other values gets an
id.*
Each description that influences one or more other values gets a list of
description that it influences.*
* Here we can use that a description is the same if type and accessor are
the same. I used this as well in the influences.
Sounds good.
Second pass:
Render the descriptions and add for all influences a script to update the
influenced values.**
Ok..but just to see if I understand... this is all about re-render right?
Then, at a separate layer we have the #addInfluence:for: to modify the
value of the stuff before re-rendering. Right?
What I mean is...I can re-render the influenced values but maybe they do
not do a #addInfluence:for: (yet they are re-rendered).
** Of course this will fail if we have a loop. I.e.:
First name, Sir name,
Full name --> all three are connected and then we have to think something
how to avoid a re-render loop.
Indeed. There is not way to know where the render comes from? if it come
because of the ajax or a normal one? hehehe Anyway, yes, we could probably
find a way to solve the loop, even if it is a bit dirty ;)
I will try to find time to make a basic implementation
on Monday, but I do
not promise anything. It is nice that other people try to use my stuff, so
we can improve on it.
Thanks for the good energy! That would be appreciated.
3) I am not obligued to use #group: I can use
something different, like
#dependentsGroups or something like that
Point taken. I misused group here. I probably should have introduced
another term. Do you have a good suggestion? I do not think we should
couple this to group.
#dependenciesGroup: ?
#notificationGroup:
#updaterGroup:
same of above but using the word "set" instead of group (to avoid any
confusion with Magritte groups). Like "dependenciesSet"
I think I like updaterSet the most … but maybe we can do without a
property, as it is always refers to calculated fields.
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
16 Dec
16 Dec
11:40 a.m.
In your example: state should be re-rendered if country is changed but not the other way
around.
Actually, I don't really care if the country is re-render. I mean...it's not
thaaaaaat bad. At least we are not refreshing the whole form. It's just a few fields.
I think the easiest path is that all elements of the group is re-rendered. Future usecase
could allow what you suggest here (like country not updating if I change state), but that
could be a second step of improvement if complicates stuff...
But when I think further on it: we can already determine what fields should be
re-rendered. A description is based on several other descriptions. (influences and dynamic
options). As long as this is a tree the implementation should be easy enough. You process
the description twice:
First pass:
Each description that is influenced by one or more other values gets an id.*
Each description that influences one or more other values gets a list of description
that it influences.*
* Here we can use that a description is the same if type and accessor are the same. I
used this as well in the influences.
Sounds good.
Second pass:
Render the descriptions and add for all influences a script to update the influenced
values.**
Ok..but just to see if I understand... this is all about re-render right? Then, at a
separate layer we have the #addInfluence:for: to modify the value of the stuff before
re-rendering. Right?
What I mean is...I can re-render the influenced values but maybe they do not do a
#addInfluence:for: (yet they are re-rendered).
** Of course this will fail if we have a loop. I.e.: First name, Sir name, Full name
--> all three are connected and then we have to think something how to avoid a
re-render loop.
Indeed. There is not way to know where the render comes from? if it come because of the
ajax or a normal one? hehehe Anyway, yes, we could probably find a way to solve the loop,
even if it is a bit dirty ;)
I will try to find time to make a basic implementation on Monday, but I do not promise
anything. It is nice that other people try to use my stuff, so we can improve on it.
Thanks for the good energy! That would be appreciated.
Hi Mariano,
I gave it a go and try to implement it, but I forgot that it is hard to replace a part of
a table. I can replace the entire table, or table cell contents, but not table rows. In
my manual test it worked to add multiple: 'onChange:' scripts, but when I build it
into the TableRenderer, this failed due to this problem. That is an issue with JQuery.
I do not have the time at the moment to make an entirely new renderer, but I added the
infrastructure to the QC-Magritte-Ajax. Maybe you can add your renderer to
QC-Magritte-Ajax? It would be perfect if you add an example too in QC-Magritte-Demo.
All you have to do is add an array of scripts that need to be re-rendered, instead of a
single re-render script to the call. And call: "renderContentOn: html ajaxScripts:
aList" instead of "renderContentOn: html ajaxScript: aScript"
Finally note that this could generate a lot of scripts, and that this could be a problem
for performance. It is possible to generate parametrized scripts and use those to limit
the number of scripts, but I have no experience in doing so (and so far no need, as I
solved this by re-rendering the group).
Let me know if it works out!
Cheers,
Diego
9:30 p.m.
On Mon, Dec 16, 2013 at 7:40 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi Diego,
Thanks for taking the time for giving it a try, this is very much
appreciated! I am trying to make it work, but I have a basic question.
Say I have my rendered, where I implement #basicRenderControl: to hook
there and make the scripts.... Say I have 2 related/influenced
descriptions. Problem is that at the time of the #basicRenderControl: the
related/influenced descriptions may have not yet been rendered yet since
they could be later (and hence I don't know anything, like the ID). But I
need to generate the scripts at this point, so that I can put it in the
onChange:
mmmm do you understand what I mean? I am not sure I am being clear.
Thanks,
In your example: state should be re-rendered if
country is changed but
not the other way around.
Actually, I don't really care if the country is re-render. I mean...it's
not thaaaaaat bad. At least we are not refreshing the whole form. It's just
a few fields.
I think the easiest path is that all elements of the group is re-rendered.
Future usecase could allow what you suggest here (like country not updating
if I change state), but that could be a second step of improvement if
complicates stuff...
But when I think further on it: we can already
determine what fields
should be re-rendered. A description is based on several other
descriptions. (influences and dynamic options). As long as this is a tree
the implementation should be easy enough. You process the description twice:
First pass:
Each description that is influenced by one or more other values gets an
id.*
Each description that influences one or more other values gets a list of
description that it influences.*
* Here we can use that a description is the same if type and accessor are
the same. I used this as well in the influences.
Sounds good.
Second pass:
Render the descriptions and add for all influences a script to update the
influenced values.**
Ok..but just to see if I understand... this is all about re-render right?
Then, at a separate layer we have the #addInfluence:for: to modify the
value of the stuff before re-rendering. Right?
What I mean is...I can re-render the influenced values but maybe they do
not do a #addInfluence:for: (yet they are re-rendered).
** Of course this will fail if we have a loop.
I.e.: First name, Sir
name, Full name --> all three are connected and then we have to think
something how to avoid a re-render loop.
Indeed. There is not way to know where the render comes from? if it come
because of the ajax or a normal one? hehehe Anyway, yes, we could probably
find a way to solve the loop, even if it is a bit dirty ;)
I will try to find time to make a basic
implementation on Monday, but I
do not promise anything. It is nice that other people try to use my stuff,
so we can improve on it.
Thanks for the good energy! That would be appreciated.
Hi Mariano,
I gave it a go and try to implement it, but I forgot that it is hard to
replace a part of a table. I can replace the entire table, or table cell
contents, but not table rows. In my manual test it worked to add multiple:
'onChange:' scripts, but when I build it into the TableRenderer, this
failed due to this problem. That is an issue with JQuery.
I do not have the time at the moment to make an entirely new renderer, but
I added the infrastructure to the QC-Magritte-Ajax. Maybe you can add your
renderer to QC-Magritte-Ajax? It would be perfect if you add an example too
in QC-Magritte-Demo.
All you have to do is add an array of scripts that need to be re-rendered,
instead of a single re-render script to the call. And call:
"renderContentOn: html ajaxScripts: aList" instead of "renderContentOn:
html ajaxScript: aScript"
Finally note that this could generate a lot of scripts, and that this
could be a problem for performance. It is possible to generate parametrized
scripts and use those to limit the number of scripts, but I have no
experience in doing so (and so far no need, as I solved this by
re-rendering the group).
Let me know if it works out!
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
10:03 p.m.
On Mon, Dec 16, 2013 at 5:30 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
On Mon, Dec 16, 2013 at 7:40 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi Diego,
Thanks for taking the time for giving it a try, this is very much
appreciated! I am trying to make it work, but I have a basic question.
Say I have my rendered, where I implement #basicRenderControl: to hook
there and make the scripts.... Say I have 2 related/influenced
descriptions. Problem is that at the time of the #basicRenderControl: the
related/influenced descriptions may have not yet been rendered yet since
they could be later (and hence I don't know anything, like the ID). But I
need to generate the scripts at this point, so that I can put it in the
onChange:
mmmm do you understand what I mean? I am not sure I am being clear.
Maybe we can make an assumption that the dependencies of a certain
description should be rendered first (smaller priority)?
Say, State should always be rendered after Country. In this case this is
logic, but in other descriptions not that much since the fact that they
depend on each other doesn't mean you want to display them first/latter.
Ok, but this is a trade-off.
Thoughts?
In your example: state should be re-rendered if
country is changed but
not the other way around.
Actually, I don't really care if the country is re-render. I mean...it's
not thaaaaaat bad. At least we are not refreshing the whole form. It's just
a few fields.
I think the easiest path is that all elements of the group is
re-rendered. Future usecase could allow what you suggest here (like country
not updating if I change state), but that could be a second step of
improvement if complicates stuff...
But when I think further on it: we can already
determine what fields
should be re-rendered. A description is based on several other
descriptions. (influences and dynamic options). As long as this is a tree
the implementation should be easy enough. You process the description twice:
First pass:
Each description that is influenced by one or more other values gets an
id.*
Each description that influences one or more other values gets a list of
description that it influences.*
* Here we can use that a description is the same if type and accessor
are the same. I used this as well in the influences.
Sounds good.
Second pass:
Render the descriptions and add for all influences a script to update
the influenced values.**
Ok..but just to see if I understand... this is all about re-render right?
Then, at a separate layer we have the #addInfluence:for: to modify the
value of the stuff before re-rendering. Right?
What I mean is...I can re-render the influenced values but maybe they do
not do a #addInfluence:for: (yet they are re-rendered).
** Of course this will fail if we have a loop.
I.e.: First name, Sir
name, Full name --> all three are connected and then we have to think
something how to avoid a re-render loop.
Indeed. There is not way to know where the render comes from? if it come
because of the ajax or a normal one? hehehe Anyway, yes, we could probably
find a way to solve the loop, even if it is a bit dirty ;)
I will try to find time to make a basic
implementation on Monday, but I
do not promise anything. It is nice that other people try to use my stuff,
so we can improve on it.
Thanks for the good energy! That would be appreciated.
Hi Mariano,
I gave it a go and try to implement it, but I forgot that it is hard to
replace a part of a table. I can replace the entire table, or table cell
contents, but not table rows. In my manual test it worked to add multiple:
'onChange:' scripts, but when I build it into the TableRenderer, this
failed due to this problem. That is an issue with JQuery.
I do not have the time at the moment to make an entirely new renderer,
but I added the infrastructure to the QC-Magritte-Ajax. Maybe you can add
your renderer to QC-Magritte-Ajax? It would be perfect if you add an
example too in QC-Magritte-Demo.
All you have to do is add an array of scripts that need to be
re-rendered, instead of a single re-render script to the call. And call:
"renderContentOn: html ajaxScripts: aList" instead of "renderContentOn:
html ajaxScript: aScript"
Finally note that this could generate a lot of scripts, and that this
could be a problem for performance. It is possible to generate parametrized
scripts and use those to limit the number of scripts, but I have no
experience in doing so (and so far no need, as I solved this by
re-rendering the group).
Let me know if it works out!
Thanks,
--
Mariano
http://marianopeck.wordpress.com
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
10:08 p.m.
Linking goes on Id. So you only need to put in the correct id, and it will work.
On Dec 16, 2013, at 9:30 PM, Mariano Martinez Peck wrote:
On Mon, Dec 16, 2013 at 7:40 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
In your example: state should be re-rendered if country is changed but not the other way
around.
Actually, I don't really care if the country is re-render. I mean...it's not
thaaaaaat bad. At least we are not refreshing the whole form. It's just a few fields.
I think the easiest path is that all elements of the group is re-rendered. Future usecase
could allow what you suggest here (like country not updating if I change state), but that
could be a second step of improvement if complicates stuff...
But when I think further on it: we can already determine what fields should be
re-rendered. A description is based on several other descriptions. (influences and dynamic
options). As long as this is a tree the implementation should be easy enough. You process
the description twice:
First pass:
Each description that is influenced by one or more other values gets an id.*
Each description that influences one or more other values gets a list of description
that it influences.*
* Here we can use that a description is the same if type and accessor are the same. I
used this as well in the influences.
Sounds good.
Second pass:
Render the descriptions and add for all influences a script to update the influenced
values.**
Ok..but just to see if I understand... this is all about re-render right? Then, at a
separate layer we have the #addInfluence:for: to modify the value of the stuff before
re-rendering. Right?
What I mean is...I can re-render the influenced values but maybe they do not do a
#addInfluence:for: (yet they are re-rendered).
** Of course this will fail if we have a loop. I.e.: First name, Sir name, Full name
--> all three are connected and then we have to think something how to avoid a
re-render loop.
Indeed. There is not way to know where the render comes from? if it come because of the
ajax or a normal one? hehehe Anyway, yes, we could probably find a way to solve the loop,
even if it is a bit dirty ;)
I will try to find time to make a basic implementation on Monday, but I do not promise
anything. It is nice that other people try to use my stuff, so we can improve on it.
Thanks for the good energy! That would be appreciated.
Hi Mariano,
I gave it a go and try to implement it, but I forgot that it is hard to replace a part of
a table. I can replace the entire table, or table cell contents, but not table rows. In
my manual test it worked to add multiple: 'onChange:' scripts, but when I build it
into the TableRenderer, this failed due to this problem. That is an issue with JQuery.
I do not have the time at the moment to make an entirely new renderer, but I added the
infrastructure to the QC-Magritte-Ajax. Maybe you can add your renderer to
QC-Magritte-Ajax? It would be perfect if you add an example too in QC-Magritte-Demo.
All you have to do is add an array of scripts that need to be re-rendered, instead of a
single re-render script to the call. And call: "renderContentOn: html ajaxScripts:
aList" instead of "renderContentOn: html ajaxScript: aScript"
Finally note that this could generate a lot of scripts, and that this could be a problem
for performance. It is possible to generate parametrized scripts and use those to limit
the number of scripts, but I have no experience in doing so (and so far no need, as I
solved this by re-rendering the group).
Let me know if it works out!
Hi Diego,
Thanks for taking the time for giving it a try, this is very much appreciated! I am
trying to make it work, but I have a basic question.
Say I have my rendered, where I implement #basicRenderControl: to hook there and make the
scripts.... Say I have 2 related/influenced descriptions. Problem is that at the time of
the #basicRenderControl: the related/influenced descriptions may have not yet been
rendered yet since they could be later (and hence I don't know anything, like the ID).
But I need to generate the scripts at this point, so that I can put it in the onChange:
mmmm do you understand what I mean? I am not sure I am being clear.
Thanks,
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
10:27 p.m.
On Mon, Dec 16, 2013 at 6:08 PM, Diego Lont <diego.lont(a)delware.nl> wrote:
Linking goes on Id. So you only need to put in the
correct id, and it will
work.
Yes, i know, but same problem. How do I know the ID of a component that
will be rendered later?
Do we assume all components will use #labelId for setting internally the ID
to whatever tag they use?
So with childAt: I can get all components (even those not yet rendered) and
ask for #labelId expecting that will be the real used ID?
Because passing the id as an argument to renderContentOn: html ajaxScript:
and friends would imply some changes....
Thoughts?
Thanks!
On Dec 16, 2013, at 9:30 PM, Mariano Martinez Peck
wrote:
On Mon, Dec 16, 2013 at 7:40 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi Diego,
Thanks for taking the time for giving it a try, this is very much
appreciated! I am trying to make it work, but I have a basic question.
Say I have my rendered, where I implement #basicRenderControl: to hook
there and make the scripts.... Say I have 2 related/influenced
descriptions. Problem is that at the time of the #basicRenderControl: the
related/influenced descriptions may have not yet been rendered yet since
they could be later (and hence I don't know anything, like the ID). But I
need to generate the scripts at this point, so that I can put it in the
onChange:
mmmm do you understand what I mean? I am not sure I am being clear.
Thanks,
--
Mariano
http://marianopeck.wordpress.com
In your example: state should be re-rendered if
country is changed but
not the other way around.
Actually, I don't really care if the country is re-render. I mean...it's
not thaaaaaat bad. At least we are not refreshing the whole form. It's just
a few fields.
I think the easiest path is that all elements of the group is
re-rendered. Future usecase could allow what you suggest here (like country
not updating if I change state), but that could be a second step of
improvement if complicates stuff...
But when I think further on it: we can already
determine what fields
should be re-rendered. A description is based on several other
descriptions. (influences and dynamic options). As long as this is a tree
the implementation should be easy enough. You process the description twice:
First pass:
Each description that is influenced by one or more other values gets an
id.*
Each description that influences one or more other values gets a list of
description that it influences.*
* Here we can use that a description is the same if type and accessor
are the same. I used this as well in the influences.
Sounds good.
Second pass:
Render the descriptions and add for all influences a script to update
the influenced values.**
Ok..but just to see if I understand... this is all about re-render right?
Then, at a separate layer we have the #addInfluence:for: to modify the
value of the stuff before re-rendering. Right?
What I mean is...I can re-render the influenced values but maybe they do
not do a #addInfluence:for: (yet they are re-rendered).
** Of course this will fail if we have a loop.
I.e.: First name, Sir
name, Full name --> all three are connected and then we have to think
something how to avoid a re-render loop.
Indeed. There is not way to know where the render comes from? if it come
because of the ajax or a normal one? hehehe Anyway, yes, we could probably
find a way to solve the loop, even if it is a bit dirty ;)
I will try to find time to make a basic
implementation on Monday, but I
do not promise anything. It is nice that other people try to use my stuff,
so we can improve on it.
Thanks for the good energy! That would be appreciated.
Hi Mariano,
I gave it a go and try to implement it, but I forgot that it is hard to
replace a part of a table. I can replace the entire table, or table cell
contents, but not table rows. In my manual test it worked to add multiple:
'onChange:' scripts, but when I build it into the TableRenderer, this
failed due to this problem. That is an issue with JQuery.
I do not have the time at the moment to make an entirely new renderer,
but I added the infrastructure to the QC-Magritte-Ajax. Maybe you can add
your renderer to QC-Magritte-Ajax? It would be perfect if you add an
example too in QC-Magritte-Demo.
All you have to do is add an array of scripts that need to be
re-rendered, instead of a single re-render script to the call. And call:
"renderContentOn: html ajaxScripts: aList" instead of "renderContentOn:
html ajaxScript: aScript"
Finally note that this could generate a lot of scripts, and that this
could be a problem for performance. It is possible to generate parametrized
scripts and use those to limit the number of scripts, but I have no
experience in doing so (and so far no need, as I solved this by
re-rendering the group).
Let me know if it works out!
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
18 Dec
18 Dec
3:26 p.m.
On Mon, Dec 16, 2013 at 6:08 PM, Diego Lont
<diego.lont(a)delware.nl> wrote:
Linking goes on Id. So you only need to put in the correct id, and it will work.
Yes, i know, but same problem. How do I know the ID of a component that will be rendered
later?
Do we assume all components will use #labelId for setting internally the ID to whatever
tag they use?
So with childAt: I can get all components (even those not yet rendered) and ask for
#labelId expecting that will be the real used ID?
Because passing the id as an argument to renderContentOn: html ajaxScript: and friends
would imply some changes....
Hi Mariano,
I would simply create a local dictionary where I link all description to a
"ajaxId". I render a div around each element with the ajaxId, and each time I
need an id for a description I do a lookup in this dictionary. If absent --> create new
id.
Cheers,
Diego
Thoughts?
Thanks!
On Dec 16, 2013, at 9:30 PM, Mariano Martinez Peck wrote:
On Mon, Dec 16, 2013 at 7:40 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
In your example: state should be re-rendered if country is changed but not the other way
around.
Actually, I don't really care if the country is re-render. I mean...it's not
thaaaaaat bad. At least we are not refreshing the whole form. It's just a few fields.
I think the easiest path is that all elements of the group is re-rendered. Future usecase
could allow what you suggest here (like country not updating if I change state), but that
could be a second step of improvement if complicates stuff...
But when I think further on it: we can already determine what fields should be
re-rendered. A description is based on several other descriptions. (influences and dynamic
options). As long as this is a tree the implementation should be easy enough. You process
the description twice:
First pass:
Each description that is influenced by one or more other values gets an id.*
Each description that influences one or more other values gets a list of description
that it influences.*
* Here we can use that a description is the same if type and accessor are the same. I
used this as well in the influences.
Sounds good.
Second pass:
Render the descriptions and add for all influences a script to update the influenced
values.**
Ok..but just to see if I understand... this is all about re-render right? Then, at a
separate layer we have the #addInfluence:for: to modify the value of the stuff before
re-rendering. Right?
What I mean is...I can re-render the influenced values but maybe they do not do a
#addInfluence:for: (yet they are re-rendered).
** Of course this will fail if we have a loop. I.e.: First name, Sir name, Full name
--> all three are connected and then we have to think something how to avoid a
re-render loop.
Indeed. There is not way to know where the render comes from? if it come because of the
ajax or a normal one? hehehe Anyway, yes, we could probably find a way to solve the loop,
even if it is a bit dirty ;)
I will try to find time to make a basic implementation on Monday, but I do not promise
anything. It is nice that other people try to use my stuff, so we can improve on it.
Thanks for the good energy! That would be appreciated.
Hi Mariano,
I gave it a go and try to implement it, but I forgot that it is hard to replace a part of
a table. I can replace the entire table, or table cell contents, but not table rows. In
my manual test it worked to add multiple: 'onChange:' scripts, but when I build it
into the TableRenderer, this failed due to this problem. That is an issue with JQuery.
I do not have the time at the moment to make an entirely new renderer, but I added the
infrastructure to the QC-Magritte-Ajax. Maybe you can add your renderer to
QC-Magritte-Ajax? It would be perfect if you add an example too in QC-Magritte-Demo.
All you have to do is add an array of scripts that need to be re-rendered, instead of a
single re-render script to the call. And call: "renderContentOn: html ajaxScripts:
aList" instead of "renderContentOn: html ajaxScript: aScript"
Finally note that this could generate a lot of scripts, and that this could be a problem
for performance. It is possible to generate parametrized scripts and use those to limit
the number of scripts, but I have no experience in doing so (and so far no need, as I
solved this by re-rendering the group).
Let me know if it works out!
Hi Diego,
Thanks for taking the time for giving it a try, this is very much appreciated! I am
trying to make it work, but I have a basic question.
Say I have my rendered, where I implement #basicRenderControl: to hook there and make the
scripts.... Say I have 2 related/influenced descriptions. Problem is that at the time of
the #basicRenderControl: the related/influenced descriptions may have not yet been
rendered yet since they could be later (and hence I don't know anything, like the ID).
But I need to generate the scripts at this point, so that I can put it in the onChange:
mmmm do you understand what I mean? I am not sure I am being clear.
Thanks,
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
19 Dec
19 Dec
3:37 a.m.
On Wed, Dec 18, 2013 at 11:26 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
On Mon, Dec 16, 2013 at 6:08 PM, Diego Lont
<diego.lont(a)delware.nl> wrote:
Hi Diego,
That's a good idea!!! OK. I have it clear in my mind now. I will try to
implement it soon...
Thanks!
Linking goes on Id. So you only need to put in
the correct id, and it
will work.
Yes, i know, but same problem. How do I know the ID of a component that
will be rendered later?
Do we assume all components will use #labelId for setting internally the
ID to whatever tag they use?
So with childAt: I can get all components (even those not yet rendered)
and ask for #labelId expecting that will be the real used ID?
Because passing the id as an argument to renderContentOn: html
ajaxScript: and friends would imply some changes....
Hi Mariano,
I would simply create a local dictionary where I link all description to a
"ajaxId". I render a div around each element with the ajaxId, and each time
I need an id for a description I do a lookup in this dictionary. If absent
--> create new id.
Cheers,
Diego
Thoughts?
Thanks!
--
Mariano
http://marianopeck.wordpress.com
On Dec 16, 2013, at 9:30 PM, Mariano Martinez
Peck wrote:
On Mon, Dec 16, 2013 at 7:40 AM, Diego Lont <diego.lont(a)delware.nl>wrote;wrote:
Hi Diego,
Thanks for taking the time for giving it a try, this is very much
appreciated! I am trying to make it work, but I have a basic question.
Say I have my rendered, where I implement #basicRenderControl: to hook
there and make the scripts.... Say I have 2 related/influenced
descriptions. Problem is that at the time of the #basicRenderControl: the
related/influenced descriptions may have not yet been rendered yet since
they could be later (and hence I don't know anything, like the ID). But I
need to generate the scripts at this point, so that I can put it in the
onChange:
mmmm do you understand what I mean? I am not sure I am being clear.
Thanks,
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
In your example: state should be re-rendered if
country is changed but
not the other way around.
Actually, I don't really care if the country is re-render. I mean...it's
not thaaaaaat bad. At least we are not refreshing the whole form. It's just
a few fields.
I think the easiest path is that all elements of the group is
re-rendered. Future usecase could allow what you suggest here (like country
not updating if I change state), but that could be a second step of
improvement if complicates stuff...
But when I think further on it: we can already
determine what fields
should be re-rendered. A description is based on several other
descriptions. (influences and dynamic options). As long as this is a tree
the implementation should be easy enough. You process the description twice:
First pass:
Each description that is influenced by one or more other values gets an
id.*
Each description that influences one or more other values gets a list
of description that it influences.*
* Here we can use that a description is the same if type and accessor
are the same. I used this as well in the influences.
Sounds good.
Second pass:
Render the descriptions and add for all influences a script to update
the influenced values.**
Ok..but just to see if I understand... this is all about re-render
right? Then, at a separate layer we have the #addInfluence:for: to modify
the value of the stuff before re-rendering. Right?
What I mean is...I can re-render the influenced values but maybe they do
not do a #addInfluence:for: (yet they are re-rendered).
** Of course this will fail if we have a loop.
I.e.: First name, Sir
name, Full name --> all three are connected and then we have to think
something how to avoid a re-render loop.
Indeed. There is not way to know where the render comes from? if it come
because of the ajax or a normal one? hehehe Anyway, yes, we could probably
find a way to solve the loop, even if it is a bit dirty ;)
I will try to find time to make a basic
implementation on Monday, but I
do not promise anything. It is nice that other people try to use my stuff,
so we can improve on it.
Thanks for the good energy! That would be appreciated.
Hi Mariano,
I gave it a go and try to implement it, but I forgot that it is hard to
replace a part of a table. I can replace the entire table, or table cell
contents, but not table rows. In my manual test it worked to add multiple:
'onChange:' scripts, but when I build it into the TableRenderer, this
failed due to this problem. That is an issue with JQuery.
I do not have the time at the moment to make an entirely new renderer,
but I added the infrastructure to the QC-Magritte-Ajax. Maybe you can add
your renderer to QC-Magritte-Ajax? It would be perfect if you add an
example too in QC-Magritte-Demo.
All you have to do is add an array of scripts that need to be
re-rendered, instead of a single re-render script to the call. And call:
"renderContentOn: html ajaxScripts: aList" instead of "renderContentOn:
html ajaxScript: aScript"
Finally note that this could generate a lot of scripts, and that this
could be a problem for performance. It is possible to generate parametrized
scripts and use those to limit the number of scripts, but I have no
experience in doing so (and so far no need, as I solved this by
re-rendering the group).
Let me know if it works out!
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
10 Dec
10 Dec
6:39 p.m.
New subject: Error: Name not found: Base
Ciao,
i work with a Pharo 2.0 20628 image.
I report error: [Pharo-dev] MessageNotUnderstood: SmallInteger>>isEmpty to
<pharo-dev(a)lists.pharo.org>
After i first do: ( ConfigurationOfSeaside3 project version: '3.1.0') load
and test it ( it work fine ).
Now the ((Smalltalk at: #ConfigurationOfQCMagritte) project version: '0.2')
load: #( 'Demo' )
erase the error :
MetacelloMCVersionSpec(Object)>>error:
MetacelloMCVersionSpec>>resolveToLoadableSpec:forMap:packages: in Block: [^ self
error: 'Name not found: ' , aString]
MetacelloMCVersionSpec>>packageNamed:forMap:ifAbsent:
MetacelloMCVersionSpec>>resolveToLoadableSpec:forMap:packages:
MetacelloMCVersionSpec>>resolveToLoadableSpecs:map: in Block: [:req | (self...
Set>>do:
MetacelloMCVersionSpec>>resolveToLoadableSpecs:map:
MetacelloMCVersionSpecLoader>>resolveToLoadableSpecs
MetacelloMCVersionSpecLoader>>load
MetacelloMCVersion>>executeLoadFromArray:
MetacelloMCVersion>>fetchRequiredFromArray: in Block: [:dict | ^ self
executeLoadFromArray: anArray]
MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in
Block: [^ aBlock value: dict]
BlockClosure>>on:do:
MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
MetacelloMCVersion>>fetchRequiredFromArray: in Block: [self versionSpec loader:
newLoader....
BlockClosure>>ensure:
MetacelloMCVersion>>fetchRequiredFromArray: in Block: [[self versionSpec loader:
newLoader....
MetacelloPharoPlatform>>do:displaying: in Block: [aBlock value]
BlockClosure>>ensure:
RPackageSet class>>withCacheDo:
MetacelloPharoPlatform>>do:displaying: in Block: [:bar | ...
BlockClosure>>cull:
Job>>run in Block: [result := block cull: self]
BlockClosure>>on:do:
Job>>run in Block: [self prepareForRunning....
BlockClosure>>ensure:
Job>>run
MorphicUIManager(UIManager)>>displayProgress:from:to:during:
ByteString(String)>>displayProgressFrom:to:during:
MetacelloPharoPlatform>>do:displaying:
I wrong something ?
I can load QCMagritte with Seaside 3.1.0 ?
Thanks for any considerations
Dario
6:49 p.m.
New subject: Error: Name not found: Base
I forgot:
Ciao,
i work with a Pharo 2.0 20628 image.
I report error: [Pharo-dev] MessageNotUnderstood: SmallInteger>>isEmpty to
<pharo-dev(a)lists.pharo.org>
After i first do: ( ConfigurationOfSeaside3 project version: '3.1.0') load
and test it ( it work fine ).
Now the ((Smalltalk at: #ConfigurationOfQCMagritte) project version: '0.2')
load: #( 'Demo' )
erase the error :
Error: Name not found: Base
MetacelloMCVersionSpec(Object)>>error:
MetacelloMCVersionSpec>>resolveToLoadableSpec:forMap:packages: in Block: [^ self
error: 'Name not found: ' , aString]
MetacelloMCVersionSpec>>packageNamed:forMap:ifAbsent:
MetacelloMCVersionSpec>>resolveToLoadableSpec:forMap:packages:
MetacelloMCVersionSpec>>resolveToLoadableSpecs:map: in Block: [:req | (self...
Set>>do:
MetacelloMCVersionSpec>>resolveToLoadableSpecs:map:
MetacelloMCVersionSpecLoader>>resolveToLoadableSpecs
MetacelloMCVersionSpecLoader>>load
MetacelloMCVersion>>executeLoadFromArray:
MetacelloMCVersion>>fetchRequiredFromArray: in Block: [:dict | ^ self
executeLoadFromArray: anArray]
MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
in Block: [^ aBlock value: dict]
BlockClosure>>on:do:
MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
MetacelloMCVersion>>fetchRequiredFromArray: in Block: [self versionSpec loader:
newLoader....
BlockClosure>>ensure:
MetacelloMCVersion>>fetchRequiredFromArray: in Block: [[self versionSpec loader:
newLoader....
MetacelloPharoPlatform>>do:displaying: in Block: [aBlock value]
BlockClosure>>ensure:
RPackageSet class>>withCacheDo:
MetacelloPharoPlatform>>do:displaying: in Block: [:bar | ...
BlockClosure>>cull:
Job>>run in Block: [result := block cull: self]
BlockClosure>>on:do:
Job>>run in Block: [self prepareForRunning....
BlockClosure>>ensure:
Job>>run
MorphicUIManager(UIManager)>>displayProgress:from:to:during:
ByteString(String)>>displayProgressFrom:to:during:
MetacelloPharoPlatform>>do:displaying:
I wrong something ?
I can load QCMagritte with Seaside 3.1.0 ?
Thanks for any considerations
Dario
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
11 Dec
11 Dec
4:32 p.m.
New subject: I can't load QCMagritte into Phro 2.0
Hi,
yesterday i submit to this wiki a question titled: Error: Name not found: Base
At today i don't solve the problem.
I'm interested to understund the new QCMagritte support, but i can't load it
into Pharo 2.0
>
> i work with a Pharo 2.0 20628 image.
>
> Yesterday i report error: [Pharo-dev] MessageNotUnderstood:
SmallInteger>>isEmpty to <pharo-dev(a)lists.pharo.org>
As Eliot write in <pharo-dev(a)lists.pharo.org> I suspect you have an older,
buggy, VM. What does the VM say to -version
( you can view my answer into <pharo-dev(a)lists.pharo.org> )
>
> After i first do: ( ConfigurationOfSeaside3 project version: '3.1.0')
load
>
> and test it ( it work fine ).
>
But Seaside is load and work fine.
Now the ((Smalltalk at: #ConfigurationOfQCMagritte) project version: '0.2') load:
#( 'Demo' )
erase the error :
Error: Name not found: Base
MetacelloMCVersionSpec(Object)>>error:
MetacelloMCVersionSpec>>resolveToLoadableSpec:forMap:packages: in Block: [^ self
error: 'Name not found: ' , aString]
MetacelloMCVersionSpec>>packageNamed:forMap:ifAbsent:
MetacelloMCVersionSpec>>resolveToLoadableSpec:forMap:packages:
MetacelloMCVersionSpec>>resolveToLoadableSpecs:map: in Block: [:req | (self...
Set>>do:
MetacelloMCVersionSpec>>resolveToLoadableSpecs:map:
MetacelloMCVersionSpecLoader>>resolveToLoadableSpecs
MetacelloMCVersionSpecLoader>>load
MetacelloMCVersion>>executeLoadFromArray:
MetacelloMCVersion>>fetchRequiredFromArray: in Block: [:dict | ^ self
executeLoadFromArray: anArray]
MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in
Block: [^ aBlock value: dict]
BlockClosure>>on:do:
MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
MetacelloMCVersion>>fetchRequiredFromArray: in Block: [self versionSpec loader:
newLoader....
BlockClosure>>ensure:
MetacelloMCVersion>>fetchRequiredFromArray: in Block: [[self versionSpec loader:
newLoader....
MetacelloPharoPlatform>>do:displaying: in Block: [aBlock value]
BlockClosure>>ensure:
RPackageSet class>>withCacheDo:
MetacelloPharoPlatform>>do:displaying: in Block: [:bar | ...
BlockClosure>>cull:
Job>>run in Block: [result := block cull: self]
BlockClosure>>on:do:
Job>>run in Block: [self prepareForRunning....
BlockClosure>>ensure:
Job>>run
MorphicUIManager(UIManager)>>displayProgress:from:to:during:
ByteString(String)>>displayProgressFrom:to:during:
MetacelloPharoPlatform>>do:displaying:
I wrong something ?
I can load QCMagritte with Seaside 3.1.0 ?
I need to load ConfigurationOfQCMagritte-DiegoLont.19 ?
Thanks for any consideration.
Dario
3789
days inactive
3798
days old
27 comments
4 participants
participants (4)
-
Diego Lont -
dtrussardi＠tiscali.it -
Mariano Martinez Peck -
Stephan Eggermont