I have a requirement for a Magritte-generated Seaside component where the visibility of some of the model's property is dependent on the values of other properties. Something like this. descriptionMaidenName
I am still using lr.251 and asking the following questions to the list.
Thanks,
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
> I am still using lr.251 and asking the following questions to the list.
> 1) Is there a response to my requirement in more recent Magritte versions? No. > 2) Has this topic already been covered in this list? Yes, also see the first question on <http://www.lukas-renggli.ch/smalltalk/magritte/faq>. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Thanks Lukas, I already knew about that trick. But it only works when the component is initially built, and I would need the component to change its view as the model changes without creating a new component. So it looks as if I will have to extend the framework somehow. > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Lukas Renggli > Sent: lundi, 28. septembre 2009 10:44 > To: Magritte, Pier and Related Tools ... > Subject: Re: Conditional visibility > > > I am still using lr.251 and asking the following questions > to the list. > > 1) Is there a response to my requirement in more recent > Magritte versions? > > No. > > > 2) Has this topic already been covered in this list? > > Yes, also see the first question on > <http://www.lukas-renggli.ch/smalltalk/magritte/faq>. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by Lukas Renggli
On 28 Sep 2009, at 09:43, Lukas Renggli wrote: >> I am still using lr.251 and asking the following questions to the >> list. >> 1) Is there a response to my requirement in more recent Magritte >> versions? > > No. > >> 2) Has this topic already been covered in this list? > > Yes, also see the first question on > <http://www.lukas-renggli.ch/smalltalk/magritte/faq>. > > Lukas > The magritte-scriptaculous package does what you want dynamically. This defines additional properties on the accessor as in the following example. descriptionLicenceForCA ^MAStringDescription new accessor: (#licenceForCA asAccessor visible: #isInCalifornia); label: 'Licence # (California)'; addCondition: [ :v | v size between: 5 and: 10 ] labelled: 'Please enter licence number'; priority: 80; bePersisted; beRequired; beEditable; yourself The sub-accessors are stored as properties of the main accessor. Additional sub-accessors available are: #tooltip: #readonly: #visible: #options: (dynamically compiled lists for select lists) #cssClasses: Mementos ======== Since the additional accessors refer to methods on the real model object you cant use the conventional mementos because they hold the state of the form in a dictionary and this has none of the behaviour of a real object. To solve this there is an alternative Magritte- RealMemento package which supplies almost equivalent mementos which use copies of the actual model object to store the cached state. e.g. MARealCheckedMemento etc. The main difference being that only one cache of the whole object structure is kept in the MARealCheckedMemento, related objects (sub- forms aka internal/external edited objects) must use an MAStraitMemento. A little care has to be taken to make the mementos work with sub-form objects. The #copyForMemento method is available for any fine tuning of the memento creation process. For example related objects need to be copied, and any internal structure within the object needs to be consistent. In the example bellow the related objects are explicitly copied, and the internal relationship between the personal, and billing object is re-established between the copies. E.g. copyForRealMemento super copyForRealMemento. shipping := shipping copyForRealMemento. billing := billing copyForRealMemento. personal syncPersonalWithBilling: billing Components ========== descriptionState ^ super descriptionState beRequired; componentClass: MASelectListComponentSU; yourself MASelectListComponentSU - differs from the standard SelectList in that it triggers an scriptaculous update of the entire form, when the selection is changed. In this case, when the user selects the state of california in the billing address sub-form, the "Licence for CA" field appears in the personal data sub-form. best regards Keith _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
erratum
postCopyForRealMemento super postCopyForRealMemento.
Keith _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
addendum:
The Magritte-Scriptaculous package also defines a third accessor to all objects. in addition to readUsing: and write:Using: there is added update:Using. This allows the changing component (e.g. MASelectListComponentSU to apply any changes to a different selector, so that the model can respond dynamically to the change. E.g. description010CustomerName ^ MAStringDescription new accessor: (#customerName asAccessor update: #customerNameChangedTo; options: #customerNamesAvailable); label: 'Customer Name'; fieldSize: 30; propertyAt: #filter put: #matchLeft; componentClass: MAAutoCompletingTextInputComponent; beSearchable; bePersisted; yourself best regards Keith _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Free forum by Nabble | Edit this page |