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.
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
Hi All,
I noticed that in Pillar-Model-DamienCassou.88 there was a refactor that introduces traits into the project...
Refactor parameter management
- Move parameter-related methods from PRLink/PRScript to PRTParametrizable
- Extract parameter-related parsin to PRParameterParser
As nice as traits are, this makes Pillar and things that depend on it, like Pier, less cross platform.
Given the ideal would of maintaining as much cross-platform-abiltty as possible, would you prefer we create multiple code bases for Pillar/Pier, or refactor this refactor in preference to making the project available in other dialects of Smalltalk, notably GemStone?
I seem to remember there was a rumour that GemStone will support traits in the future, so it’s likely we’ll have the option to shift to traits in the future.
I have an old project using Pier in GemStone that I’m starting to upgrade, so my motivation here is to know what direction the Pillar/Pier team would prefer to take, then jump on board with whichever direction you choose.
Please chime in with any thoughts. What are your preferences for moving forward?
Cheers,
J
Hi Christophe,
On 18-06-15 11:27, Christophe Demarey wrote:
> A small thing I just noticed: You have an extension method on Collection>>copyWithAll: in the Magritte-Model package.
> Its implementation is the same as Collection>>,
> Maybe you could just use Collection>>, instead.
Hmm, old stuff, interesting. No idea why that was added. Let's see if
someone on the mailing list knows.
Are there smalltalks without , on Collection?
Stephan
Hi,
We've been using Margritte-Seaside for about 6 years now. And we've
been hacking around and monkey patching magritte to force it into
submission.
I'm trying to improve on this approach, as you may agree. I would in
general like to understand Margritte better, but perhaps start with:
how do you suggest we customise the rendering of a described
component? We know of a few hooks, but is there some documentation I
can read on this subject?
I know my question is vague, but I have so many, and would like to
just start somewhere and then dive into more specifics. Please let me
know if I should dive into specifics.
Further, is this the best mailing list to post on?
Thanks
Otto
I'm working on an experiment to work with Magritte descriptions via a GUI
generated by Magritte itself. For example, bring up a Magritte form on
description, edit it, and then save as a description method on an object.
As an initial spike, MADescription>>#constructorSource:, which for e.g.:
```
MANumberDescription new
default: 5;
constructorSource.
```
returns:
```
^ MANumberDescription new
default: 5;
yourself
```
One thing I noticed is that descriptions do not have meta-descriptions of
their accessors. Does anyone know why?
Is anyone using the meta-features of the descriptions themselves as
described in the Magritte white papers (or any other way for that matter!)?
Has anything like this been done? It seems strange to me if not...
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Meta-Magritte-tp4832184.html
Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com.
Hi,
I have a QCBMagritteReport (a subclass of MAReport) with a command column
with options to perform on each row:
addColumn:
(MACommandColumn new
addCommandOn: self selector: #edit: text: 'Edit';
addCommandOn: self selector: #delete: text: 'Delete';
addCommandOn: self selector: #validate: text: 'Check';
yourself)
This works well, however I would like to see a Bootstrap drop down button
as opposed to individual links being shown. I've experimented with
QCCommandColumn but without success (it needs something in its component
instance variable but I'm clueless as to what).
Is there a specialised renderer for this I can use or should I implement my
own?
Thanks for reading.
Roger
I have a default Magritte edit form for a model that maintains a relation
to a single instance of GeoLocation, a model object with two instance
variables: longitude and latitude. The relation is defined as a
MAToOneRelationDescription.
On the form, the instance of GeoLocation is displayed as the integer of the
longitude attribute, however I want a representation like:
lon: 12.67, lat: 34.09
I looked at MAToOneRelationDescription and its superclass
MAElementDescription implements a #display: method which either accepts a
symbol or a block to customize the display. I've implemented a #printString
method with GeoLocation and passed that to the relation description as:
display: #printString
and
display: [ :anObject | ^ anObject printString ]
But as far as I can tell both the symbol and the block get ignored when
displaying the GeoLocation instance in the Magritte form.
What should I change to get the required display?
Thanks,
Roger
