Magritte: descriptions for classes that use different constructors then new

Hi all,

I have a situation that brings up a couple of questions.

I have 2 classes which have a class side variable which keeps track of
the instances created (much like how Pier's PRKernel works).  As a
consequence, I need these objects to be instantiated, not with #new,
but with a special message (e.g. #named:).

The second part of the equation is that, while these two classes have
their own Magritte definitions and can display themselves, there is a
"main site" component that displays all the instances from these two
classes, as options for the user.  So this puts me in a situation
where the main site class needs to have descriptions
(MAToManyDescription I believe) that reference the other two objects
(i.e. the main site class wont have any instVars for these).  And for
added fun, this class has a class side method named #description for
the Seaside framework.

Now, I think the issue with the main site is not so bad, I would just
define my #description methods as normal, right?  Since #description
is taken already I guess I have to override it on the instance side
and call MANamedBuilder for: myself?

And the other question is, how do I enforce that when Magritte wants
to make a new instance of these other two classes that it uses my
custom constructor, not #new?  Since the custom constructor is going
to expect a portion of the data already, I'm guessing I need some kind
of Memento?  I suppose I could just let it create the object with new,
and then have the accessor create the "real" object from this, but
that seems very cheesy.

Thanks for any help you can provide,
Jason

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> Now, I think the issue with the main site is not so bad, I would just
> define my #description methods as normal, right?  Since #description
> is taken already I guess I have to override it on the instance side
> and call MANamedBuilder for: myself?

Yes, that's the simplest possibility.

> And the other question is, how do I enforce that when Magritte wants
> to make a new instance of these other two classes that it uses my
> custom constructor, not #new?

Magritte does not have the possibility to specify a different  
constructor.

> Since the custom constructor is going
> to expect a portion of the data already, I'm guessing I need some kind
> of Memento?  I suppose I could just let it create the object with new,
> and then have the accessor create the "real" object from this, but
> that seems very cheesy.

Yes, if you have descriptions for your constructor arguments you can  
use the MAAdaptiveModel to let the user enter the constructor data  
and then you feed these values into the constructor itself. I guess  
there is no easier way.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On 10/16/07, Lukas Renggli <[hidden email]> wrote:
>
> Yes, that's the simplest possibility.

I saw some stuff on Ramon's blog that answered my question (I must
say, I knew this blog was good, but I didn't realize how much great
info was there).

> Yes, if you have descriptions for your constructor arguments you can
> use the MAAdaptiveModel to let the user enter the constructor data
> and then you feed these values into the constructor itself. I guess
> there is no easier way.

Well, that's not bad.  I'm just glad it's doable at all.  From taking
a quick look, it seems I can just make a CustomizedConstructorMemento
to do this job.  I can change the model to be the *class* instead of
an instance of the class, and change the push method to first
construct the class, then apply the remaining values.  Hrm, actually I
guess model will need to be the class on first use, and an instance of
the class after data is committed to it once.

But on an unrelated note, while exploring my options with accessors I
think I may have uncovered a bug.  I was using autoselector, which
made instance variables in my class and accessors for them (handy when
you need it!).  I switched to selectorAccessor to stop this behavior
and now I get the following:


MessageNotUnderstood: Set>>copyFrom:to:

Debug Proceed Full Stack
Possible Causes

    * you sent a message this type of object doesn't understand

Stack Trace

   1.

      thisContext
          Set(Object)>>doesNotUnderstand: #copyFrom:to:
      self
          a Set()
      aMessage
          copyFrom: 1 to: 0

   2.

      thisContext
          MAReport>>visible
      self
          a MAReport

   3.

      thisContext
          MAReport>>renderTableBodyOn:
      self
          a MAReport
      html
          a WARenderCanvas
      row
          nil
      index
          nil
      col
          nil

   4.

      thisContext
          [] in MAReport>>renderTableOn: {[self showBody ifTrue: [self
renderTableBodyOn: html]]}
      self
          a MAReport
      html
          a WARenderCanvas

   5.

      thisContext
          BlockContext>>renderOn:
      self
          [] in MAReport>>renderTableOn: {[self showBody ifTrue: [self
renderTableBodyOn: html]]}
      aRenderer
          a WARenderCanvas


I'm still investigating the cause of this, but I thought I would post
it real fast in case someone knows off the top of their head.

Thanks,
Jason

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> But on an unrelated note, while exploring my options with accessors I
> think I may have uncovered a bug.  I was using autoselector, which
> made instance variables in my class and accessors for them (handy when
> you need it!).  I switched to selectorAccessor to stop this behavior
> and now I get the following:

The following change should fix this:

Name: Magritte-Seaside-lr.245
Author: lr
Time: 16 October 2007, 6:15:06 pm
UUID: fc88afbe-e0b7-4a92-a3a5-859f94a3efc6
Ancestors: Magritte-Seaside-lr.244

- fixed a problem reported by Jason Johnson when suddenly a Set ended  
up in a report

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Awesome, thanks.  That was fast work! :)

On 10/16/07, Lukas Renggli <[hidden email]> wrote:
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki