smallwiki

smallwiki@list.inf.unibe.ch

2312 discussions

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

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

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

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

Re: ConfigurationOfSeaside 1.0.3 is available

by Dale Henrichs

14 years, 10 months

Re: ConfigurationOfSeaside 1.0.3 is available

by Dale Henrichs

14 years, 10 months

ConfigurationOfSeaside 1.0.3 is available

by Dale Henrichs

ConfigurationOfSeaside is Metacello configuration that provides easy access to Seaside2.8 or Seaside3.0, Magritte and Pier for Squeak and Pharo (soon GemStone, too). To download ConfigurationOfSeaside evaluate the follow expression in Pharo: (Smalltalk at: #Gofer) new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside'; load. or the following expressio in Squeak: (Installer squeaksource project: 'MetacelloRepository'; packagesMatching: 'ConfigurationOfSeaside-*') first install. After downloading ConfigurationOfSeaside evaluate one of the following expressions: ConfigurationOfSeaside project latestVersion load: #('Seaside 2.8' 'Seaside 2.8 Examples' 'Magritte Tests' 'Pier Tests' 'Pier AddOns'). or ConfigurationOfSeaside project latestVersion load: #('Seaside 3.0' 'Seaside 3.0 Tests' 'Magritte2 Tests' 'Pier2 Tests' 'Pier2 AddOns'). depending upon whether you want to work with Seaside3.0 or Seaside2.8. Both Seaside 3.0 and Seaside 2.8 cannot coexist in the same image, so you have to make a choice. You can edit the literal array to include only the components that you want loaded into your image. If you want the latest bleeding edge mcz files for Seaside3.0, Magritte, and Pier evaluate the following expression: (Smalltalk at: #Gofer) new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPier'; load. ((Smalltalk at: #ConfigurationOfPier) project version: '2.0.3-baseline') load: 'ALL'. Version 1.0.3 is based upon the latest mcz files in the collective Seaside repositories as of this afternoon PST. I've tested ConfigurationOfSeaside on Squeak (trunk and Squeak3.10.2-7179-basic) and Pharo (PharoCore-1.0-10508rc2). Note that there was an issue with loading Psome Pier2 code into Squeak3.10.2-7179-basic. The same code loaded fine into the Squeak trunk. If you want finer control over what is loaded into your image, you can pick and choose from the following Metacello configurations in http://www.squeaksource.com/MetacelloRepository: "Seaside 2.8" ConfigurationOfSeaside28 ConfigurationOfSeaside28Examples ConfigurationOfMagritte ConfigurationOfPier ConfigurationOfPierAddOns "Seaside 3.0" ConfigurationOfSeaside30 ConfigurationOfMagritte2 ConfigurationOfPier2 ConfigurationOfPierAddOns2 As you can imagine, it is easier to use ConfigurationOfSeaside to get started. Dale

14 years, 10 months

checkins: PUSecurityWidget and PRTagCloudWidget

by Nick Ager

Hi, I've checked in a couple of changes: Pier-Security-NickAger.162 "removed editUser hack from PUSecurityWidget by adding PUEditUser command" The motivation for this change was that the existing edit user hack was ignoring the editing environment I wanted to use (see http://www.iam.unibe.ch/pipermail/smallwiki/2010-February/005763.html) Pier-TagCloud-NickAger.16 "added additional stop words" Hope these work for everyone Nick

14 years, 10 months

Re: Reorganization of Pier 2 and Magritte 2 Repositories

by Dale Henrichs

14 years, 10 months

Perl does Magritte

by Ch Lamprecht

Hello, for quite some time I have been experimenting with a Perl implementation of Magritte. It was great fun and a good way to learn about OO design. I'm not a professional and there are probably lots of bugs, but the basic things seem to work. If anyone is intrested and wants to take a look, it can be found here: http://sites.google.com/site/vlclamprecht/Home/perl Thanks to Lukas for his work! Cheers, Christoph

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