On Wed, Apr 15, 2015 at 9:53 PM, Yanni Chiu <[hidden email]> wrote:

On Apr 15, 2015, at 8:01 PM, Cameron Sanders via Pharo-users <[hidden email]> wrote:
>
> Sure, I am happy to share. We are to the point that we need to get people interested in this platform; one thing we offer is a source license and therefore we need to document things that we have not yet documented.
>
> So please, fire away any questions.

Are there any instances of Magritte framework that are not an instances of a custom subclass? (Did you have to subclass everything?)

No, we did not have to subclass everything. But quite some. For example, the components, yes, we have to subclass them all. The main reasons are more or less these:

1) We want everything to be ajaxfied (so every single component needed to be rewritten for AJAX)

2) We want all our components to use Bootstrap layout

3) We want components/descriptions/renderes/etc that better fit our own needs

4) We needed more hooks

The only part that we did subclass everything is the components. Then we have subclasses some descriptions but not all. We also have some special descriptions.

In addition, we have subclassed:

- Memento: to provide extra hooks....

- StringWriters: mostly to change the way we print floats, dateandtime, dates, etc.

- TableRenderer: because we have 2-columns and 1-column type of form (and to layout these forms using Bootstrap)

- FormDecoration and ValidationDecoration: to provide ajax and bootstrap

- DescribedColumn, CommandColumn, etc: we have lots of subclasses to specify and improve our magritte reports

- other...

 

What pushed you toward custom subclasses? Was the properties dictionary not sufficient for extending the object state variables, or was it a speed/performance issue? Would refactoring the Magritte classes to have various hook methods allowed you to avoid making custom subclasses? (I found that it was Twitter Bootstrap which drove the need for subclassing the framework, whereas native HTML would have been adaptable to Magritte’s needs).

We DO extend some of Magritte superclasses using extension methods that use the properties. We have quite some properties extended that way. However, many other places we need to change the way things are displayed, or arranges, or provide more hooks, to better fit our need etc. In that case, just using properties is not enough. 

Yes, if we would have had more hooks, we likely would have need to subclass less. But not everything. We think Magritte was easy enough to extend as is. Another thing we found is that sometimes is a bit hard to agree on what is needed for all magritte users. So fully refactoring Magritte may affect other developers or other use-cases of Magritte.  

 

Did you use the OneToOne and OneToMany relationship descriptions by subclassing, or did you create entirely new ones?

We have subclasses those. Why? Because we found out that it asks the #optionsAndLabels quite a lot of times when it is not really necessary. For example, to view an object, it needs to send #optionsAndLabels just to then search the label for an specific option.... So we have created our own "lazy" subclass of those 2 were #optionsAndLabels are computed as much lazy/late as possible AND we can also plug a #getLabelClosure which avoids getting #optionsAndLabels just for that...

In addition to this, we have some special components (for example one that uses autocomplete) and so the combination of lazy descriptions + autocomplete component is very useful for long lists. 

 

What are some statistics on your model - e.g. number to classes? average (mean/median/mode) number of attributes/methods per class? average depth of the class hierarchy?

We'll have to get back to you on that one -- if we ever count them...

Do you translate/map the “Smalltalk” query blocks for GemStone to get better speed, or is this unnecessary?

Yes. But only in a few places. We have currently 3 or 4 places where we have indexes in GemStone collections. So what we did is that we have a QueryBuilder strategy, with 2 subclasses, one for Pharo and one for GemStone. And a singleton #current. Each class knows how to answer the query closure for a particular query. It simply answers the closure we then pass to the #select:. GemStone one will answer the { }  one. 

 

Do you use Magritte descriptions to tag things for indexing on GemStone? Or, do you just manually create indexes on GemStone as necessary (e.g. via install code that encapsulates knowledge of where to index, or does the system automatically raise flags when indexing is needed).

The latter. We do not use Magritte here. 

 

From various postings, I gather you have a lot of data to process. Do you have any numbers like:
- total number of objects in the system

This is tricky, because it really depends on the advisory firm or the researcher. Quuve is deployed for each customer. So the size really really varies. 

 

- biggest collection, typical collection size

Right now for example we are dealing with storage of fundamental data of companies (for research) , and prices... some collections have a few million objects. What is important is that you must analyze which collection class to use. Best (from our point of view) is one that supports both, RC and Indexes. Just in case you need any of those later.