magritte-metamodel / magritte Goto Github PK

Version: 3.0.1

If we have an element description, but don't supply a label, there is still a 
label cell with only a $: in it (which would've been appended to the supplied 
label name). 

Two possible defaults:
* capitalize the accessor
* leave the label out completely if not supplied

The Magritte documentation at http://book.seaside.st needs to be updated for 
Magritte 3, see for example 
http://book.seaside.st/book/advanced/magritte/first-examples

I implemented MADynamicDescribedObject to avoid having to specify #kind: on 
descriptions when materialising xml using  #fromXml:

However the Json implementation #fromJson: doesn't require 
MADynamicDescribedObject. 
I view MADynamicDescribedObject as a hack that should be removed to simplify 
the core Magritte code.

I think Magritte-XMLBindings should be refactored so that #fromXml: can work in 
a similar way to #fromJson: and won't require the support of 
MADynamicDescribedObject which can then be removed

see also: http://code.google.com/p/magritte-metamodel/issues/detail?id=8 
(Magritte-json and Magritte-xml have divergent implementations)

See http://forum.world.st/Model-actions-td4693208.html

and needs a heavy cleanup.

This is in Magritte-Seaside-lr.335 ... #caption is sent to a 
description, but I haven't found any implementors ... is this a bug 
waiting to happen or is magic involved:)

Response from Lukas:


  Actually I don't know where MAReportComponent is coming from?

  Seems to be a long obsolete class, it should be removed. I don't see
  how it can work. Use MAReport.

And Morphic support...

Was loading up Pharo 1.1 and noticed that Magritte-Model
SequenceableCollection>>reduce: and String>>lines overrides what's
already in Pharo and breaks some Pharo unit tests.  I assume this
isn't intentional and Pharo has recently added these methods.

Reported by Ramon Leon

Magritte-Json and Magritte-xml have very different implementations, even though 
they are performing similar functions.
Also the magritte APIs are different. For example:
* Magritte-Json has a default serialisation scheme which is modifiable via 
description properties.
* Magritte-XMLBindings will not serialise until #xmlElementName: has been 
defined. 

Please find some bugs, so that they can be fixed.

MASelectListComponent>>renderEditorForGroupedOn: sends #dispatchCallback:
to a select tag, but no such method exist.

In Morphic:
1. Click the "Edit" button on an item in a ToMany list
2. In the form that pops up, click cancel

The item label is 'nil', but if you open the container freshly, the item is 
still there intact.

What steps will reproduce the problem?
1. go to /seaside/magritte/editor
2. select 1:m Relation
3. Click Add

What is the expected output?

Not sure... something?

What do you see instead?

Seaside Walkback

MessageNotUnderstood: UndefinedObject>>asArray

Debug Proceed Full Stack

Possible Causes

the receiver of the message is nil
a class extension hasn't been loaded correctly
you sent the wrong message
Stack Trace

thisContext
UndefinedObject(Object)>>doesNotUnderstand: #asArray
self
nil
aMessage
asArray
exception
MessageNotUnderstood: UndefinedObject>>asArray
resumeValue
nil
thisContext
MAReport>>cache
self
a MAReport
thisContext
MAReport>>hasMoreThanOnePage
self
a MAReport
thisContext
MAReport>>renderTableOn:
self
a MAReport
html
a WARenderCanvas
thisContext
[] in MAReport>>renderContentOn:
self
a MAReport
html
a WARenderCanvas

What version of the product are you using? On what operating system?

1.2 one-click

e.g. For single option relationships, we currently have a list view. It would 
be nice to also have dropdown or radio

I've been struggling with a Magritte validation problem. I find that a 
condition I add (using #addCondition:labelled:) to a MABooleanDescription is 
only intermittently called.

I've simplified the conditions to reproduce the problem to a component 
description comprising of two MABooleanDescription descriptions. The second 
description includes the condition which is intermittently called.

If the value of the first description is true (ie the checkbox is checked) the 
second description's condition will be executed, however if it is false it will 
never be executed.

I suspect the problems lies in the code in  
MAValidatorVisitor>>#visitContainer: which calls MAGraphVisitor>>#use:during: 
which is as follows:

MAGraphVisitor >>use: anObject during: aBlock
    | previous |
    (seen includes: anObject)
        ifTrue: [ ^ self ].
    anObject isNil
        ifFalse: [ seen add: anObject ].
    previous := object. object := anObject.
    aBlock ensure: [ object := previous ]

If the first check box is false, and the second is also false then (seen 
includes: anObject) will return true and method returns early resulting in 
block associated with second description (self visit: description) never being 
executed. 

I've attached a file out of a simple component TestMagritteValidation 
illustrating the problem that I tested in the latest build from Hudson.

Thanks
Nick 

Version 3.0.1
Even when readOnly: is set to true, the field is editable

It's been integrated into the kernel and is only needed for 2.0

** Hold until requested. I needed this, but worked around it for the time 
being. If it comes up again, here's the result of my initial investigation...

The idea is to allow model constraints (e.g. between the parent and the new 
reference) to be set up before the new object is viewed.

Implementation notes:
1. The To Many Morph/Component would send "description initialize: self 
selected" instead of "self selected new"
2. MAToManyRelationDescription>>#initialize: aBlock (taking a class as an 
argument

Would be used like:

    MAToManyRelationDescription new
        accessor: #events;
        label: 'Events';
    classes: { MyDomainClass AnotherClass };
    initialize: [ :klass | klass new date: self date ].

Use case:
Parent has many children, which it holds internally in a Dictionary.
If one was going to add a child programmatically, one would do something like:
Parent>>#addChild: aChild number: 3
  children at: 3 put: aChild

where the 3 appears to be (in the model) a property of the child, even though 
its really held as the key in the children dictionary. 

I want:
- the number to appear as a number editor in the new child editor, even though 
it's not really a property of the child. Like a virtual field
- the addition of a new element in a toMany relationship to be overridable; 
right now it happens in e.g. MAOneToManyMorph. I'd like it to delegate to the 
description, so that a user could say (pseudocode): 
  description addBlock: [ :collection :newElement | 
    collection at: newElement number put: newElement ].

What I discovered is that, since Dictionary>>#add: takes an association, a 
workaround is to create an Association subclass, which has the number (3 above) 
as its key, and aChild as its value, and add one instead of adding a Child.

E.g. 
    Association subclass: #IndexToChildAssociation

    IndexToChildAssociation>>descriptionIndex
    <magritteDescription>   
    ^ MANumberDescription new
        label: 'Index';
        selectorAccessor: #key.

    IndexToChildAssociation>>descriptionChild
    <magritteDescription>
    ^ MAToOneRelationDescription new
        label: 'Child';
        selectorAccessor: #value;
        classes: { Child }.

And then...

    descriptionChildren
    <magritteDescription>   
    ^ MAToManyRelationDescription new
        selectorAccessor: #children;
        classes: { IndexToChildAssociation. Child }.

Notice that the real model class (Child) must be included in #classes: or 
you'll get a validation error when trying to save a parent that already has 
children.

The StringMorphs are set to a default width. If the label is short, everything 
looks okay. But if the label is longer, the extra length of the text goes 
behind the view for the field data.

I tried changing to TextMorph instead, which solves the problem above, but then 
the fields aren't lined up. We need some kind of grid layout/morph