smallwiki

smallwiki@list.inf.unibe.ch

2312 discussions

by Reza RAZAVI

At 10:25 27/02/2010, Lukas Renggli wrote: >Load the latest Seaside-Pharo-Tools-Web and the latest RBF server. I >fixed various minor problems, but it basically worked already before. Hi Lukas, This is to confirm that it works perfectly. I just tried it successfully both under OSX by Chicken of the VNC and under Vista by TightVNC. The issue was basically related to my firewall configuration. Thank you again, and my apologies for the delayed feedback due to other obligations. Regards, Reza

14 years, 9 months

Dynamic pages and something like WATask for pier

by Norbert Hartl

Hi, I'm experimenting at the moment with "dynamic pages". I just need to extend the static pages by one level. I did a subclass of PRPage that answers true on hasChildren call so that PRPathLookup does accept the path being requested. If the page is really requested the last path component is taken as query for an object. I then take a "template page" copy its document and set the parent to the right page. Beside having the need for returning a dummy page on a children call this works out pretty good. If you understand that rather cryptic description :) you may have some hints about that. The second approach is to have something like WATask in pier style. The pages shouldn't be directly accessible via URL. The task should work on editabel pier pages that pass/inject the right objects into page. Let's say there is a three steps task I want to solve. I would start by taking on template page (copying its document) and embedding the first form. On answer it will take the next template page and injects the results from the previous step into the new page. This would lead to a task where the textual decoration and such could be changed by editors and the task by programmers. I'm sorry but I don't know how I can explain that in a more understandable fashion. But maybe you understand it and have some hints or pointers how to approach that use case. Norbert

14 years, 9 months

MAInternalEditorComponent error

by dtrussardi＠tiscali.it

Hi, i work with Magritte-Model-lr.394 on pharo. I have a MAAccountModel with descriptionCodice and descriptionIndirizzoMemo. The last is defined as: descriptionIndirizzoMemo ^ (MAToOneRelationDescription new) componentClass: MAInternalEditorComponent ; classes: (Array with: MAIndirizzoModel); selectorAccessor: 'indirizzoMemo'; label: 'Indirizzo'; comment: 'Indirizzo di riferimento'; priority: 220; "beReadonly;" yourself Now MAIndirizzoMemoModel is defined with some other description: descrptionCitta descriptionNumero and other description. ( You can load the file mcz. ) Now when open: MAAccountModel new asComponent i found the error: MessageNotUnderstood: receiver of "isMultipart" is nil isMultipart ^ self children anySatisfy: [ :each | each isMultipart ] The error is erase only with componentClass set to : MAInternalEditorComponent. Any considerations ? Thanks, Dario

14 years, 9 months

Magritte import an existing project

by stan shepherd

Hi, is there a utility to automate the 'Magritte-ising' of an existing project? I imagine it would scan the classes, and create the class side descriptors and missing accessors automatically. It would seem useful for quickly evaluating/prototyping what Magritte could add to the current project. I thought I read about this before, but I can't find a reference or any class that seems to do it. Thanks, ...Stan

14 years, 9 months

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

14 years, 9 months

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, 10 months

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, 10 months

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, 10 months

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, 10 months

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, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki