Default labels
by Sean P. DeNigris
In cases where there is an MASelectorAccessor, I'd like to make the default
label = `the accessor capitalized unCamelCased`. It seems the overwhelmingly
common use case is `... #accessor: #dateCreated; #label: 'Date Created'`.
The current behavior is
MADescription>>#label
^ self propertyAt: #label ifAbsent: [ self class defaultLabel ]
Is anyone using (or can state a plausible use case for) this
subclass-customizable class-side #defaultLabel?
If no one is relying on the existing behavior, I'll make the change...
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Default-labels-tp4827879.html
Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com.
5 years, 3 months
Photo gallery?
by Damien Cassou
Hi,
is there any photo gallery available for Pier? I mean a widget where I
could upload pictures and they are rendered in a nice way. I started
one 4 years ago but I abandoned it.
Bye
--
Damien Cassou
http://damiencassou.seasidehosting.st
5 years, 4 months
Improving Magritte
by Diego Lont
Hi all,
Recently there was a question about Magritte extensions on the Pharo users list. It has been a while that I was really involved in developing on (QC)Magritte and doing stuff on the web, but on my todo list, there is feeding back the improvements on Magritte I have made for QCMagritte to Magritte itself. And while doing so, adding tests and cleaning up code where needed.
The first extension I would like to feed back into Magritte is the Builder.
The background of the builder is the following:
- Having a custom component set, and wanting to use this custom component set can be very tiresome for larger applications, because you have to set a component class for all descriptions.
- Also it breaks the layering Magritte is trying to build in, as you need to "pollute" your model descriptions, with all kind of stuff, that determine how everything looks like. With stuff that belongs in your UI code instead of your model code.
I believe that the builder is a solution for this problem. The actual builder can be injected as an extension (for an example see the QCMagritte demo) and processes all descriptions. As it is a visitor, it can replace or enrich your descriptions with whatever you need in your UI based on the type of description.
The builder affects the way the Magritte description is created, so the package contains an override of magritteDescription. If I would implement this on Object (the most logical point), I would need to put the builder into Magritte-Model. Having no builders, this would of course not affect the returned description. Does anyone object to putting this here? And if you have objections, do you have a suggestion to do this elsewhere?
Cheers,
Diego
5 years, 7 months
Is there an Undo/Versioning solution based on Magritte?
by Esteban A. Maringolo
Hi all,
I'm trying to implement a way to have versions of the contents entered
through a form so I can revert the object models to an early state,
very much like the page history edits in Wikipedia, but with more
fields than just the text content.
This solution should provide a feature to store the contents not only
of the descriptions in the container, but also descriptions contained
in referenced descriptions (via MAReferenceDescription).
I'm about to write my own, but if there is something out there, I
would like to see if it fits our needs, or could be easily modified.
Regards!
Esteban A. Maringolo
5 years, 7 months
Re: QCMagritte: QCObject vs. QCParentObject
by Esteban A. Maringolo
This is why I call it "ModelPart", because the parent/child relation is
alike but not always so. It's "part" of a whole (its owner), but not
necessarily a child.
Also the relation is of aggregation, the lifetime of the part is, as much,
as long as the lifetime of its owner.
I.e. an InvoiceIem is part of an Invoice but won't exist if the invoice is
deleted.
Regards,
El abr. 30, 2017 12:10 PM, "Stephan Eggermont" <stephan(a)stack.nl> escribió:
On 29/04/17 14:40, Diego Lont wrote:
> Good point. When no one objects I will rename QCParentObject into
> QCChildObject.
>
Hmm. Aren't they all children? Isn't the more important aspect ownership?
Let's iterate over the name some more.
Stephan
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.list.inf.unibe.ch/listinfo/smallwiki
6 years, 1 month
QCMagritte: QCObject vs. QCParentObject
by Udo Schneider
All,
I can't really understand the difference between QCObject and
QCParentObject and when to use which.
From reading the source I can guess that a QCParentObject allows you to
access the ApplicationModel using #model (through it's parent ivar). But
is this all?
CU,
Udo
6 years, 1 month
