Ramon Leon a écrit : What do you mean "using pragmas" ? Can you give us a simple example please ? Do you mean a pragma to avoid starting method names by "description" ? I don't think so but it should be easily done if not already.

Yes, it is doable and there was an implementation some time ago in the Magritte-Model package. The class was called MAPragmaBuilder a subclass of MADescriptionBuilder. - The reason that there were no examples was because code using Pragmas cannot be loaded into 3.7 and 3.8 images, and we still have a few of those that work with the latest version of Magritte. I know that others are using Magritte with older Squeak versions as well. - Therefor I removed MAPragmaBuilder from Magritte-Model, in one of the latest cleaning efforts as it was never used ... now that you ask, it might have been the wrong decision. You can reload it by browsing the code of Magritte-Model-lr.228 and load the class. To activate it you need to evaluate: MADescriptionBuilder default: MAPragmaBuilder new Then you can put your descriptions in a method like: Address class>>street <description> ^ MAStringDescription selector: #street You can use class extensions to extend existing descriptions from a different package: Address class>>streetAddendum: aDescription <description: #street> ^ aDescription beReadonly It doesn't matter much for speed. And this implementation is conceptually very close to the naming convention. PS: I think it would be better to actually put the descriptions into accessors (move them to to instance-side), but this means to change a few others things and I didn't find the time to do that yet. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oh... You're just trying to avoid the description naming pattern, I see. I was thinking something more along the lines of something on the accessors directly... Post>>author <description: #SingleOption label: 'Author'> <options: #findAuthors> <relatedTo: #SBAuthor> <displayField: #asString> <required: true> ^author Post>>comments <description: #ToManyRelation label: 'Comments'> <relatedTo: #Comment> ^comments Post>>title <description: #String label: 'Title'> <required: true> <length: 150> ^title Post>>body <description: #Memo label: 'Body'> <required: true> ^body Post>>isPublished <description: #Boolean label: 'Published?'> <default: true> ^isPublished And generating Magritte descriptions from the metadata and not using class side descriptions at all. Or maybe just by default, and falling back on class side descriptions for complex cases. Ramon Leon http://onsmalltalk.com

Yea, one of the things I love about Magritte, everything's pluggable. If I do it, which I very likely will, I'll definitely contribute it. Ramon Leon http://onsmalltalk.com

hi ramon I thought about that too. The questions after is how much extensibility do we want. I do not have the answer just meat questions: Will we have the declare new pragmas each time you add a new property to a description. Do we really want that? what are the benefits? over class side single description? I think that this is not clear to me what is really the gain to have fine-grained pragmas. On 8 janv. 07, at 23:44, Lukas Renggli wrote:

Contrast Magritte with Glorp, both are very powerful, and very pluggable. Magritte provides meta data about a class, Glorp needs that same metadata for its descriptions. Magritte is a runtime meta data system, Pragmas are compile time meta data. However, both Glorp and Magritte require explicit meta data in the form of code, stored away from the accessor the meta data belongs to. Pragmas however, allow one to keep the metadata for a selector, in the selector itself, a very pleasing option because while I don't mind the description building bouncing around following description Pragmas, I'd rather the developer didn't have to, and much of the meta data contained within Magritte descriptions, really is just compile time meta data. Obviously Pragmas are less flexible than class side descriptions, I'm not at all suggesting there's anything wrong with Magritte, it's great, but it could be simpler to configure, just like Glorp vs. Rails. Most of the time, when doing database bound web applications, I think one really could use Pragmas like Rails uses macros to give hints to the description builder to automate the construction of "MOST" descriptions, possibly all. It'd be really elegant if one made a field required by simply adding the <required> Pragma to the accessor itself, and then having the runtime generate both the Magritte and Glorp descriptions off the class meta data allowing Rails like behavior and no code required by the developer. For the more complex cases, you could always have the builder follow <description: #authorDescription> to the manually configured class side descriptor, but seriously, most cases will be simple mappings of Strings, Numbers, Dates, and Memo fields directly to a matching field in the database, and those, the most common cases, can be totally automated and work off Pragmas alone. Rails has proven the attraction of zero configuration to the masses, and if Ruby can do it, Smalltalk can do it better. I'm already building an ActiveRecord implementation that builds Glorp descriptions from Magritte's meta data (working well so far), but while doing so, it just occurred to me that most of what I need for Glorp could come directly from Pragmas, and it'd be a shame to build the meta data twice, so I just thought why not build Magritte descriptors from Pragmas as well. It's just an idea, but one I think I'm going to explore a little to see where it leads. Of course, I'll share anything worthy of sharing if anything pans out, if not, oh well, I'm sure I'll have fun in the process. Ramon Leon http://onsmalltalk.com