Disable control area in Pier

>> The draw-back, there is usually one, would be that retrieving
>> the descriptions would be more expensive as they cannot be
>> cached anymore.
>
> Why it can be cached anymore? Can't just be posible to refactor the  
> cache subsystem to work instance based intead of class based?

Yes, that should be possible. However Squeak has inherent problems  
with dictionaries having more than 4000 elements, and even worse,  
with weak finalization; two things that are very likely to be needed  
for an instance-based description cache.

> I know that some systems allready have instance based caches. Some  
> of them:
>
> GOODS client by Avi Bryant,
> rST,
> OmniBase support

Yes, I know GOODS, it gets very slow when the caches grow. OmniBase  
uses a slightly different approach and has its own fast  
implementation of an IdentityDictionary.

> PD: I'm not familiar with Magritte and recently interested in it  
> because I
> think it make archivable that an application could have a  
> maintainable web
> interface and desktop interface at a reasonably cost.

True, however the builder for desktop-interfaces probably needs some  
more work to be useable in production ;-)

Cheers,
Lukas

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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> Well, being slower, doesn't at all imply that it's too slow, so a  
> better question is in the overall rendering of a page, say a  
> complex edit form, what percentage of total rendering time is taken  
> by retrieving the description both cached and uncached. I mean, it  
> could be dwarfed by the call to goods(or whatever db you use) to  
> actually retrieve the objects, and if that's the case, running  
> uncached may not even be noticeable.

Yes, this is true, it won't be noticeable at least for building GUIs:  
the description is only read once before visiting the descriptions  
and building the interface. It becomes more of a speed problem when a  
query is done over a graph with many described objects.

> Caching may not be necessary at all, in the larger scheme of  
> things, and frankly, I find myself flushing the cache constantly,  
> especially during development.

Why that? The cache is automatically flushed when descriptions change  
in your code.

Lukas

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



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> Ok, doesn't seem to work, but let me explain what I'm doing.  I'm
> writing a component meant to be hosted in Pier, the component has
> several settings it needs, and I was using class side descriptions to
> provide the "settings" interface that Pier offers on any component.

Yes, this is the usual procedure.

> However, looking at PRSettingsComponent, I see that it's not asking  
> the
> instance for it's description, it's asking the class directly,  
> bypassing
> any overrides I may have attempted on the instance side.  Is that the
> intention?

Oups, this seems to be a bug. I fixed it and will publish my changes  
as soon as I have a propre internet connectionn again.

> Am I writing components wrong?  Should I be subclassing
> something in Pier rather than my own WAComponent subclass?

No nothing wrong from your side. You could also subclass PRStructure  
(as the model) and define the settings on there (to make editing  
work). Then you could also define views and other commands.

> The Magritte tutorial is great btw, is there something similar for  
> Pier?

No, not yet, only the SmallWiki paper from WikiSymposium that is  
still valid for a big part (minus the name).

> Now that Pier seems somewhat stable, I'm starting to explore it more
> as an application container with configurable widgets, digging it so
> far, just need to get a few things done so I grok the do's and  
> dont's a
> little better.  Great work though, keep it up!

Thanks a lot!

Cheers,
Lukas

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



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

>> The Magritte tutorial is great btw, is there something similar for  
>> Pier?
>
> No, not yet, only the SmallWiki paper from WikiSymposium that is  
> still valid for a big part (minus the name).

And the documents I wrote: http://smallwiki.unibe.ch/smallwiki/pier


--
Damien Cassou


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> Yes, this is true, it won't be noticeable at least for building GUIs:  
> the description is only read once before visiting the descriptions  
> and building the interface. It becomes more of a speed problem when a  
> query is done over a graph with many described objects.

Ah, I hadn't considered querying.

>>things, and frankly, I find myself flushing the cache constantly,  
>>especially during development.
> Why that? The cache is automatically flushed when descriptions change  
> in your code.

Maybe just a habit I got into, looking over other code, I see use of
MADynamicObject to handle binding of lists that may change and can't be
cached, I think this was the original reason I started flushing the
cache.  Also, while in development, sometimes I feel like the cache
didn't flush when I changed a description, however, there's a good
chance that's just a bad perception on my part, like last night when I
was trying to do an instance side description override... felt the cache
wasn't flushing, turned out instead that SettingsComponent had a bug
instead.


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> The reason it is so slow is basically the use of #allSelector, that could be  
>improved (with more clever code or pragmas). Still I guess the factor  
>of 10^3 would stay the same.
>
maybe putting all descriptions in a single class side method (a
Container) could do the job but that's not really nice ;)

Cédrick




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

_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki