Yanni, please find my answers below.
On Thu, Apr 16, 2015 at 10:57 AM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:
>
>
> On Wed, Apr 15, 2015 at 9:53 PM, Yanni Chiu <ya...@rogers.com> wrote:
>
>>
>> On Apr 15, 2015, at 8:01 PM, Cameron Sanders via Pharo-users <
>> pharo-users@lists.pharo.org> 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.
>
>
>
--
Mariano
http://marianopeck.wordpress.com
