smallwiki March 2010

smallwiki@list.inf.unibe.ch

13 participants
23 discussions

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

14 years, 1 month

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

14 years, 1 month

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

14 years, 1 month

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

14 years, 1 month

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

14 years, 1 month

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 >

14 years, 1 month

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 >

14 years, 1 month

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 >

14 years, 1 month

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

14 years, 1 month

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

14 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki March 2010