[Feature]: Add a Field in 3 Simple Steps
by Sean P. DeNigris
This is something I've been dreaming about for a long time, and finally had
some time to implement. Next step: integrate with browser, and possible
offer as a refactoring…
Motivation: Define a descripton on a class, along with instVar, getter and
setter, in three easy steps.
Example Usage:
```smalltalk
MyClass maAddField: #employeeNumber.
```
1. A list of MADescription subclasses will appear; select one.
2. Next fill out a Morphic Magritte form on a prototype of your selection
from #1
3. An annotated description-creation method will be added to MyClass. If you
gave the description an MASelectorAccessor, the instVar, getter, and setter
will be created if needed.
-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Magritte-Pier-and-Related-Tools-f115649.html
5 years, 9 months
Condition Handling - WIP?
by Sean P. DeNigris
I'm wondering whether conditions could be fleshed out some more or if I'm
missing some intention/design…
I was employing a technique described by Ramon Leon [1] for conditions that
affect multiple descriptions, namely:
```
descriptionContainer
^(super descriptionContainer)
addCondition: [:memento |
(memento cache at: self descriptionEndDate) > (memento cache at:
self descriptionStartDate)]
labelled: 'End date must be after start date';
yourself
```
I noticed a few seeming limitations of this technique (and conditions in
general):
1. The example above only works when using a cached memento. It fails due to
DNU #cache for other Memento types, as well as when validating objects
directly (e.g. `myDomainObject magritteDescription validate: self.`)
2. When the above fails, the exception bubbles up on its own instead of
being grouped together with failed conditions from individual descriptions
because `MAValidatorVisitor>>#visitContainer:` handles the container
validation separately (via `super visitContainer: aDescription.`) before
looping through the element descriptions to validate them.
3. In both the container and element validations, once one condition
per-[container | element] fails, others are not processed (for the same
[container | element]). I experimented with expanding the error handling
block, but couldn't see a great way to overcome this without a more
significant rewrite because MAValidationErrors are not resumable.
My quick fix idea would be to make MAValidationErrors resumable and expand
the error block to include the container along with the element validations.
Would that be the best way to address the issues above?
1. http://onsmalltalk.com/multiple-field-validation-rules-in-magritte
-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Magritte-Pier-and-Related-Tools-f115649.html
5 years, 9 months
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, 9 months