using , as decimal point
by Norbert Hartl
Hi,
I like to use fractions in my web forms. Unfortunately everything regarding numbers is nailed to use a dot (.) as decimal separator. In magritte it should be fairly easy to delegate the decimal point to the MANumberDescription but then there is still Number class>>readFrom: that checks for dot as well.
Do you have any ideas how to treat this case? I'm not sure if converting at the appropriate locations is feasible.
Norbert
13 years
Pier user management
by Nick Ager
Hi,
Does any know of any Pier add-ons (or Seaside add-ons) for user management?
I'm looking for functionality such as:
* Handling users forgetting their password
* logging on using OpenID
* reporting on users who haven't logged on within a specified period.
Yours lazily
Nick
13 years
Re: Contextual #call: issue
by Reza RAZAVI
At 21:48 11/03/2010, Nick Ager wrote:
>If there's a mismatch between the environment used within a
>rendering-callback cycle that's going to confuse Seaside when it
>processes the callbacks.
That sounds a very good point too; thanks Nick!
I've to look at what happens more closely, since now I've some clicks
"lost", in the sense that when I push the command's link, its
execution is not visible, although launched. I know that the
execution is launched, since I tracked this down to
GRPharoPlatform >> seasideCallbackMarker (as said before, the
execution of this command includes calls to other components). It
appears that in theses cases, #seasideCallbackMarker finds and
returns a context, that of PRContext >> activationCallback. However,
the #call: remains ineffective in the sense that the control is not
passed to the new component!?
Later,
Regards,
Reza
13 years
Re: Contextual #call: issue
by Reza RAZAVI
Hi Nick ,
Thank you for your kind response!
At 17:46 11/03/2010, Nick Ager wrote:
>* seasideCallbackMarker produces the helpful error: "You can only
>#call: and #answer: from within a callback or a Task." So presumably
>you are using #call outside a callback
An important feature of Pier is its flexibility, in this specific
case, allowing dynamic modification of templates and components. My
concern could be formulated as follows: is there a context-sensitive
relationship between the configuration of templates/components in
Pier, and partial continuations in Seaside 3? Why it looks working
only in some configurations?!
Maybe its simply only related to my specific application case. I've
to look at it more closely.
>Perhaps examining the call stack within onAnswerCommand in the cases
>where the command causes and error and when it executes successfully
>might highlight the difference causing the problem.
Good idea. Will try it asap.
Any other thoughts would be very welcome.
Regards,
Reza
13 years
Contextual #call: issue
by Reza RAZAVI
At 17:36 26/02/2010, Nick Ager wrote:
>The solution I've finally arrived at is:
>1) I've added a method to my custom kernel #editingEnvironment
>2) I've overridden #environment in PRPierFrame so that it now reads:
>
> environment
>| environment |
>(self context command isView or: [self context command isQuick]) ifTrue: [
>environment := self context structure environment
>] ifFalse: [
>environment := self kernel editingEnvironment
>].
>
>^ environment
Hi,
I'm testing a specific type of *quick* command (#isQuick returns
true). During their execution, triggered by PRContentsWidget >>
onAnswerCommand:, they call other components (via #call:). My
configuration is Ubuntu, Pharo, Seaside 3, and Pier2.
The execution goes on smoothly when triggered via the *commands*
toolbar. However, I'm experiencing an issue in the following circomstances:
1) When trying to switch the current template just before the start
of the execution, using the above method by Nick.
2) When launching the command via an internal link, and only if I'm
not logged in.
In both cases the execution stops by the error raised in
GRPharoPlatform >> seasideCallbackMarker.
It is difficult to characterize the issue since its somehow
contextual. But, it seems that #seasideCallbackMarker is sensitive to
the components that are present in the current Pier Context.
I'd greatly appreciate any feedback on this issue.
Regards,
Reza
13 years
Re: Re[2]: [Esug-list] GSoC idea: GLORP & Magritte integration
by Mariano Martinez Peck
Ok....It is important what Alan said. However, from my point of view it is
worth to see what there is in common and in case that it is not too much,
how can we extend or modify Magritte to be that way. The student should also
look at keith's Magritte-RDB when we acutally did something similar to this
but without Glorp.
Юрий Мироненко do you want to change something to Niall proposal ? In
true, please do it as soon as possible and send me the updated version.
For the moment at the end you will find the version with my little changed
with what I said in my previous mail.
Now....we need a mentor. Diogenes Moreira offers to be the co-mentor. He
knows a lot of Glorp (he is actually developing with us SqueakDBX/GlorpDBX)
and Magritte. His main problem is that his English is not the best one ;)
So...we still need a mentor.
Volunteers ?
Refactoring model mapping commonalities from Glorp and Magritte
--------------------------------------------------------------------
Mentor: TBD Second mentor: TBD
Level
====
Glorp and Magritte both map between model-layer objects and other domains;
in Glorp's case, the relational database, in Magritte's case, the web. The
truth is that Magritte is a meta-description framework for all kind of
description. However, it is mostly used for web applications.
There are many similarities in how each framework maps model-layer class
aspects/instVars/etc. to RDB tables and fields, and to web entities.
Developers of Seaside or AidaWeb apps using RDBs, in particular, sometimes
feel they are repeating themselves when they code first the Glorp mappings
and then the Magritte mappings, or vice versa.
The goal of this project is to analyze by experiment how far common aspects
can be extracted to a single core:
- Are any limitations of one framework revealed by comparison with the
other?
- Can the API be refactored so that the same concept uses the same method
call in both frameworks?
- Can a single set of descriptor classes, extended by each framework, be a
common core to both? Can a single set of meta-model walking functions be
used by both?
- Can a single set of descriptor objects be used by both?
The output is both a refactored codeset exploiting the commonality that can
sensibly be achieved and an analysis of why more commonality cannot, or
cannot easily, be achieved
Technical Details
===========
Glorp and Magritte have good test suites. XP development to ensure existing
facilities remain functional will protect the student from breaking some
facilities as they experiment with refactorings. Maintaining deprecated
methods that call new API in terms of old API may be appropriate in the
project, and may also assist introduction of the results to the community.
Benefits to the Student
===============
Glorp and Magritte are two meta-modelling/mapping frameworks with impressive
capabilities solving real problems: the student who does this project will
acquire significant practical knowledge of this kind of meta-modelling.
Glorp and Magritte are also important parts of one way of writing web
applications: the student who does this project will have skills that can
be turned to practical account in web development.
2010/3/10 Юрий Мироненко <tallman(a)inbox.ru>
> > Magritte is not ONLY for web development descriptions, but for any
> > description.
>
> Unfortunately, it's very common to use Magritte only as a tool for
> generating web-forms. Most if not all Magritte examples are about it. Tool
> like Magritte looks very powerful...potentially :) And it's not only about
> descriptors. Memento functionality is described in pretty easy-to-understand
> way, for example. Conditions structure and validation is very funny, too. I
> personally used two described above.
>
> Firstly, I used magritte-based memento to fight GLORP limitations. GLORP
> has no nested UnitOfWorks, and you really need something in realworld
> application that will handle "save" button :). So, on "save" button pressing
> I begin UnitOfWork, commit memento and then commit UnitOfWork. It works very
> funny...but I was forced to implement my own memento class for it. There are
> two problems with Magritte mementos, and both leading to idea of
> GLORP-Magritte integration:
>
> a) Magritte's default memento try to manage parallel edits to the model
> (and well, GLORP needs something like this, isn't it?). It makes two
> "copies" of object, one for manipulating, and other for comparing to "real
> object" on commit. It gives possibility to track modification to "real
> object". made in period from making memento to commiting it. Well, it
> conflicts with GLORP proxies. Instantiating of a proxy forces Magritte think
> there are edit conflict...well, you can manage it by using not-default
> memento (Caching instead of Checking).
>
> b) Magritte's mementos can't manage model's behavior. For example, if I
> have simple object with two editable fields #price and #amount and one
> read-only field #total, it will be impossible to use Magritte's mementos to
> edit such an object. Supposing you want to observ #total during edit, i.e.
> before commit will happen. To manage this, I made a new Memento class. It
> makes a new instance of model's class for caching, and then uses every
> not-read-only Accessor to copy values from model to this class (well, it was
> little bit harder, but not much). And you see, it's very, very similar to
> GLORP caching technique.
>
> You can overlook this on http://squeaksource.com/SmallPOS.html
>
>
> Secondly, I trying to use (working on it just now) Magritte conditions not
> for just making data entry validations, but for implementing fast search and
> to build where-clauses for GLORP. And well, trying to do it I feel myself
> like...hmmm...translating from one language to another with similar semantic
> but different words :)
>
> I was forced to expand Magritte descriptor's system with "this accessor
> should return this value". And GLORP already has it.
>
> Next, GLORP's blocks parsing technique looks very promising for Magritte.
> Magritte has "plugable" condition, but it's out of Magriite concept really.
> Parsing of blocks may help a lot, combining "easy to write and read"
> advantage of blocks and "it's possible to serialise/manage programmatically"
> advantage of explicit using of special classes. GLORP uses block parsing for
> very same reasons, I believe.
>
>
> _______________________________________________
> Esug-list mailing list
> Esug-list(a)lists.esug.org
> http://lists.esug.org/listinfo/esug-list
>
13 years
Re: [Esug-list] GSoC idea: GLORP & Magritte integration
by Mariano Martinez Peck
Hi Niall. Thank you very much!! It is really interesting.
There are two things I would change, if you are agree of course. See below.
====
> Glorp and Magritte both map between model-layer objects and other domains;
> in Glorp's case, the relational database, in Magritte's case, the web.
Magritte is not ONLY for web development descriptions, but for any
description. That's why we are even considerating it for describing the
mappings.
Although it is obvious that for the web is fits very well and it is widely
used for that purpose.
> There are many similarities in how each framework maps model-layer class
> aspects/instVars/etc. to RDB tables and fields, and to web entities.
> Developers of Seaside apps using RDBs,
The other thing I would like to change is that not NECESSARY you need
seaside. I say this because maybe the student or the mentor want to use Aida
or whatever other thing. I think it should concentrate in the interaction
between Magritte and Glorp, but too much in the "user" of Magritte (seaside
or whatever).
I am not sure about this. Just a though.
What do you think ?
Cheers
Mariano
> in particular, sometimes feel they are repeating themselves when they code
> first the Glorp mappings and then the Magritte mappings, or vice versa.
>
> The goal of this project is to analyze by experiment how far common aspects
> can be extracted to a single core:
>
> - Are any limitations of one framework revealed by comparison with the
> other?
>
> - Can the API be refactored so that the same concept uses the same method
> call in both frameworks?
>
> - Can a single set of descriptor classes, extended by each framework, be
> a common core to both? Can a single set of meta-model walking functions be
> used by both?
>
> - Can a single set of descriptor objects be used by both?
>
> The output is both a refactored codeset exploiting the commonality that can
> sensibly be achieved and an analysis of why more commonality cannot, or
> cannot easily, be achieved
>
> Technical Details
> ===========
> Glorp and Magritte have good test suites. XP development to ensure
> existing facilities remain functional will protect the student from breaking
> some facilities as they experiment with refactorings. Maintaining
> deprecated methods that call new API in terms of old API may be appropriate
> in the project, and may also assist introduction of the results to the
> community.
>
> Benefits to the Student
> ===============
> Glorp and Magritte are two meta-modelling/mapping frameworks with
> impressive capabilities solving real problems: the student who does this
> project will acquire significant practical knowledge of this kind of
> meta-modelling. Glorp and Magritte are also important parts of one way of
> writing Seaside applications: the student who does this project will have
> skills that can be turned to practical account in web development.
>
> Yours faithfully
> Niall Ross
>
> Mariano Martinez Peck wrote:
>
> I am one of the developers of SqueakDBX and GlorpDBX so...of course, I
>> really like the idea. Having to create the GLORP mappings in a separate
>> class and then create also the Magritte description (for other purpose,
>> like web description) is not cool. Maybe managing all the metadata (for
>> different purpose lile web, validations, RDB mappings, etc) with the same
>> tool would be cool.
>>
>> What others think ?
>>
>> So, yes, I like it. Can you send me the proposal ? something like what it
>> is in http://gsoc2010.esug.org/ideas.html
>>
>> Someone wants to be the mentor ?
>> Cheers
>>
>> Mariano
>>
>> 2010/3/10 Юрий Мироненко <tallman(a)inbox.ru <mailto:tallman@inbox.ru>>
>>
>>
>> GLORP & Magritte both uses a lot of similar techniques. It's not
>> descriptors only. Accessors and Conditions are other examples. So,
>> why not clean up everything metamodel-related from GLORP, and
>> utilise Magritte functionality instead?
>>
>> I thing it gives boost to both projects: Magritte will be forced
>> to evolve and include techniques like collection tracking. GLORP,
>> first of all, will lost part of it's complexity. And, secondly, it
>> will be possible to use, say, Chain or Pluggable accessors.
>>
>> And there are several sinergy effects expected. First of all, we
>> avoid double-working when you try to use Magritte and GLORP in one
>> project. Yes, there are some package fir this, but it built "on
>> top" of both systems, and provide only very simple and
>> straitforward possibilities. Next, it becomes easier to implement
>> "list all objects links to this very object", which is definetly
>> in a lot of relation-databases-based applications.
>>
>> Finaly, as far as Magritte is often used (for generating forms,
>> for example), it will be funny "just add few code and force my
>> code to work with Postgresql". Really, I think, lot of people
>> described different pieces of proposed system in their own
>> projects. I personally did.
>>
>> _______________________________________________
>> Esug-list mailing list
>> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org>
>>
>> http://lists.esug.org/listinfo/esug-list
>>
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Esug-list mailing list
>> Esug-list(a)lists.esug.org
>> http://lists.esug.org/listinfo/esug-list
>>
>>
>
> _______________________________________________
> Esug-list mailing list
> Esug-list(a)lists.esug.org
> http://lists.esug.org/listinfo/esug-list
>
13 years
Re: [Esug-list] GSoC idea: GLORP & Magritte integration
by Mariano Martinez Peck
I am one of the developers of SqueakDBX and GlorpDBX so...of course, I
really like the idea. Having to create the GLORP mappings in a separate
class and then create also the Magritte description (for other purpose,
like web description) is not cool. Maybe managing all the metadata (for
different purpose lile web, validations, RDB mappings, etc) with the same
tool would be cool.
What others think ?
So, yes, I like it. Can you send me the proposal ? something like what it is
in http://gsoc2010.esug.org/ideas.html
Someone wants to be the mentor ?
Cheers
Mariano
2010/3/10 Юрий Мироненко <tallman(a)inbox.ru>
> GLORP & Magritte both uses a lot of similar techniques. It's not
> descriptors only. Accessors and Conditions are other examples. So, why not
> clean up everything metamodel-related from GLORP, and utilise Magritte
> functionality instead?
>
> I thing it gives boost to both projects: Magritte will be forced to evolve
> and include techniques like collection tracking. GLORP, first of all, will
> lost part of it's complexity. And, secondly, it will be possible to use,
> say, Chain or Pluggable accessors.
>
> And there are several sinergy effects expected. First of all, we avoid
> double-working when you try to use Magritte and GLORP in one project. Yes,
> there are some package fir this, but it built "on top" of both systems, and
> provide only very simple and straitforward possibilities. Next, it becomes
> easier to implement "list all objects links to this very object", which is
> definetly in a lot of relation-databases-based applications.
>
> Finaly, as far as Magritte is often used (for generating forms, for
> example), it will be funny "just add few code and force my code to work with
> Postgresql". Really, I think, lot of people described different pieces of
> proposed system in their own projects. I personally did.
>
> _______________________________________________
> Esug-list mailing list
> Esug-list(a)lists.esug.org
> http://lists.esug.org/listinfo/esug-list
>
13 years
PRJQuerySearchWidget
by Nick Ager
Hi,
I've added a package: "Pier-JQuery" to the repository: "Pier 2 Add-Ons" (
http://source.lukas-renggli.ch/pier2addons) The package contains a single
class PRJQuerySearchWidget. PRJQuerySearchWidget, should be a JQuery drop in
replacement for PRAjaxSearchWidget (which used Scriptaculous libraries)
The widget depends on JQuery and JQWidgetBox-FormExample-*
To download the prerequisits:
Gofer new
squeaksource: 'JQueryWidgetBox';
package: 'JQWidgetBox-Core';
package: 'JQWidgetBox-Dev';
package: 'JQWidgetBox-FormExample-Core';
package: 'JQWidgetBox-FormExample-Dev';
load.
JQWidgetExample initialize.
or:
((Smalltalk at: #ConfigurationOfJQueryWidgetBox) project version: '1.0')
load: 'JQWidgetBox-FormExample-Core';
load: 'JQWidgetBox-FormExample-Dev'.
It's working well for me, let me know if there are any problems including it
in other projects
Cheers
Nick
13 years
MAToOneRelationDescription error with MAInternalEditorComponent beReadonly property
by dtrussardi＠tiscali.it
Hi,
when i define a description based on this code :
^ (MAToOneRelationDescription new)
componentClass: MAInternalEditorComponent ;
classes: (Array with: MAIndirizzoModel);
autoAccessor: 'indirizzoMemo';
label: 'Indirizzo';
comment: 'Indirizzo di riferimento';
priority: 220;
beReadonly;
yourself
where i set beReadonly.
A) I found error when display it into:
renderViewerOn: html
html render: (self component
readonly: self isReadonly;
yourself)
because self component answer nil.
B) Another problem is relative to the same description when i rendering it as subComponent but with beReadonly setting.
When i do "Save" the container erase errors relative to this subcomponent descriptions .
But it's readOnly and d'ont do any control on it.
C) I'm interested to incorporate the subComponent at the first level ( without the create buttons )
I create a MAInternalEditorComponent subclass: #MAOneToOneDirectComponent
and change the :
buildComponent
"create new default value for directly rendering the subcomponent without button "
self value isNil ifTrue:[ self value: self selected new.
component := nil ].
^ self value isNil ifFalse: [
(self description reference asComponentOn: self value)
setParent: super;
yourself ]
It work fine.
But the rendering is with to level the master and the slave.
I can incorporate the slave description at first level ?
Thanks for any considerations.
Dario
13 years
