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

[stepharo]

thanks for the explanation.


Le 22/4/15 08:41, Cameron Sanders via Pharo-users a écrit :

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  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  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  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 -

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

[stepharo]

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 > 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 mailto: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

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

[Mariano Martinez Peck]

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.

Cheers,


On Sat, Apr 18, 2015 at 4:55 PM, stepharo  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  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

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

[stepharo]

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  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.

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

[stepharo]

Le 18/4/15 20:04, Yanni Chiu a écrit :

On Apr 18, 2015, at 2:18 AM, stepharo  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.

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

[Yanni Chiu]

On Apr 18, 2015, at 2:18 AM, stepharo  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.

> 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.

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. 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.