Re: [Pharo-users] [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used

[Cameron Sanders via Pharo-users]

--- Begin Message ---

Magritte could be improved to allow a context of usage to be specified e.g.
#tableReport, or #editor, and then allow class designers to specify the
pairs of keys for CSS style to be written for the context. We'll follow up
on this point soon.

Seaside could accept more renderingBlocks to be more customizable. And/or
Magritte descriptions should allow these to be passed down. But where does
one draw the line? Like the above paragraph on CSS, different contexts
demand different rendering blocks. So in fact, we pull together our
Magritte descriptions in non-standard ways for our most important view: the
portfolio browser. Many are created dynamically from accounting terms in a
DB, because there are thousands of possible rules/equations, and they
cannot all be hand-coded for this one class.
-

In our application, Magritte provides a mechanism to describe the
attributes (or computed terms) in order to paint an editor, a read-only
view, and/or table presentation/edit dialogs. For complex specification and
controller classes, we often still need to write dedicated Components.

We do not use Magritte for persistence, instead we use a variant of
DebrisDB that works on Gemstone & Pharo. So our CRUD solution involves our
own tables (seaside subclasses) that allow us to install blocks to
implement various behaviors such as "update table from DB". We also allow
application-level "plugin" rules to be presented as buttons and controls,
but these are very specific to our whole framework. The launching of these
tables is handled through various of our own constructs, specifically our
ApplicationContext, which knows where to put new panes/components, for
example.

Much of the speed with which we can define a new class, have it persistent
(no time using DebrisDB), and have editors/presenters (perhaps 1 to 15
minutes per instVar for simple classes), is due to the culmination of
various tools in our environment and our experience with such.

-Cam

On Tue, Apr 21, 2015 at 2:55 PM, stepharo <steph...@free.fr> wrote:

>
>
> Le 21/4/15 18:26, Mariano Martinez Peck a écrit :
>
> Hi Stef,
>
>  Similar to what Yanni said, 99% of our extensions are to
> Magritte-Seaside, not to magritte core itself. I honestly see Magritte as a
> very small and super extensible framework from which you can build your own
> on top of it. Like QCMagritte. Or likely what Yanni did, or likely what we
> did. That is...a set of subclasses/extensions to Magritte Seaside. This
> doesn't mean we shouldn't make this open-source, but I am just saying all
> our extensions should not be Magritte core code but kind of a framework
> build on top of Magritte core.
>
>  Just to give you an idea of the extensibility of Magritte... is that
> with all our framework build on top of Magritte, we had NO OVERRIDE and our
> classes/extensions load cleanly after loading Magritte.
>
>
> Ok I trust you. So this is good.
>
> Now I do not know how to do crud applications with magritte.
>
>
>  Cheers,
>
>
> On Sat, Apr 18, 2015 at 4:55 PM, stepharo <steph...@free.fr> wrote:
>
>> And BTW I would really like to see how we can do crude with
>> magritte-described objects.
>>
>>
>> Le 18/4/15 21:37, stepharo a écrit :
>>
>>
>>>
>>> Le 18/4/15 20:04, Yanni Chiu a écrit :
>>>
>>>> On Apr 18, 2015, at 2:18 AM, stepharo <steph...@free.fr> wrote:
>>>>
>>>>  I found strange that not a single little improvements of Magritte was
>>>>> necessary for the Qude project.
>>>>>
>>>> It’s not strange to me, because when working with Magritte 2, it seemed
>>>> that almost everything I wanted to do had a hook method to override, or an
>>>> obvious place to subclass or extend. So much so, that when I could not find
>>>> the extension point, I thought it was my fault. What was missing was
>>>> instance-based descriptions, which was added by the community in Magritte 
>>>> 3.
>>>>
>>>
>>> :)
>>>
>>>
>>>> Given how well-factored Magritte 2 was, my deduction was that a lot of
>>>> effort had already been done to extract out an open-source artefact, from
>>>> whatever system drove it’s development. So, no surprise that few
>>>> improvements to the core Magritte were needed.
>>>>
>>>
>>> Ok so we have perfect software. Good to know.
>>>
>>>>  Now if heavy users of open-source libraries do not enhance these
>>>>> open-source libraries and keep their extensions
>>>>> under close source then the open-source libraries will never make
>>>>> progress and I will immensely sad.
>>>>>
>>>> Given that Magritte is already well-factored for extensions, what tends
>>>> to be written is exactly the custom code which you would not be releasing
>>>> to open-source.
>>>>
>>>
>>> but you see I did not use magritte since long time. It would be great to
>>> have example of custom-code.
>>> For example are relationships any useful.
>>>
>>>>
>>>> However, there might be a case for add-ons, such as Twitter Bootstrap
>>>> support. As mentioned in another post, changing the Magritte API/interfaces
>>>> at this point is tricky, because it would affect current users - that’s the
>>>> conundrum: success and wider adoption will constrain the evolution.
>>>>
>>> We have versions to help there.
>>>
>>>  The addition of instance-based descriptions was worth the (minor) pain
>>>> of the transition, but what level of pain would be tolerable to add
>>>> Bootstrap support, especially if you’re not using Bootstrap.
>>>>
>>> But we are talking about SeasideMagritte here?
>>> I do not know because I do not have experience.
>>> I was talking about magritte.
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>  --
> Mariano
> http://marianopeck.wordpress.com
>
>
>

--- End Message ---