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
Pillar, traits, and cross platform
by Jupiter Jones
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
7 years, 9 months
Why Strings?
by Sean P. DeNigris
Converting domain objects to and from Strings seems deeply embedded in
Magritte. But sometimes, e.g. if the underlying object is text, it seems to
be more appropriate to just pass the text to the view/editor. I played a bit
with this idea but quickly got lost. Has anyone ever experimented with this
idea? Would it make sense / be possible to refactor and abstract so that
Text or another class could be plugged in instead of String? Or maybe there
are already hooks for this?
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Why-Strings-tp4840047.html
Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com.
7 years, 10 months
MIMEType no longer exist on Pharo, what do we replace it with?
by stephan
Magritte-Pharo3-Model
MAFileSystem class>>mimeTypesForExtension: aString
| types |
types := MIMEType forExtensionReturnMimeTypesOrNil: aString.
^ types ifNotNil: [ types collect: [ :e | e asString ] ].
The interface for ZnMimeType is slightly different.
Stephan
7 years, 10 months
