Fwd: Debris' Quuve - Technologies used

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Debris' Quuve - Technologies used

Pharo Smalltalk Users mailing list
Several people inquired as to how Quuve was built. Mariano wrote up a nice description of the various tools that were used to build Quuve -- see below. Note also that DebrisPublishing.com website is now up; we are still working on videos, but the site is very lean at present.

-Cam

Quuve Technologies Used


Quuve has been and still is developed with Pharo. We try to use the most up to date stable version of Pharo. Quuve is deployed in GemStone.


Package dependencies are managed via Metacello. Not only do we have many dependencies but also multiple Smalltalk environments: Pharo and GemStone. We also use Metacello to correctly load the needed packages and versions for each of the platforms.


We use Seaside as our web framework and Twitter Bootstrap for Seaside for the layout and design of the app. While some parts are still using the full-request approach, most of the app is done with AJAX and only refreshing the needed part of the screen.


We use JQuery a lot and some external JS libraries such a DataTables (for our table/reports), floatThead, HighCharts (for making charts), TinyMCE (to edit notes and a few other things), etc.


We have a full-featured CRUD system based on Magritte. Actually, we have extended Magritte so much that all our descriptions and components are actually subclasses of the original Magritte classes. We have our own descriptions, components, report column classes, mementos, table layouts, etc. All our framework is Twitter Bootstrap integrated, fully AJAX and with lots of rich features. We can make a full CRUD report/form out of Magritte descriptions in no time.


For persistency we have a library/layer which gives a unified way of saving and querying objects using a Glorp-like interface; it differs in that the where clauses are straight Smalltalk blocks. So far, when we work on Pharo we use Fuel as the "database", while for production we use GemStone. We have developed some compatibility packages so that same code would work in both Smalltalks in the way we expect. Quuve briefly used Oracle’s relational DB for persistence of its securities DB, connecting to it via the Glorp toolkit; because many mature financial DB’s are delivered in relational form, we may need to do so more extensively in the future. Although the need for this may subside as more data becomes available over REST-server interfaces.


We use NeoCSV for parsing CSV, XMLParser, Zinc-REST and STON for providing REST web services, and SIXX for moving data between Pharo and GemStone.


As to the web server, in Pharo we use Zinc, and in GemStone we use nginx + FastCGI. Quuve clients could be for example, an individual or a large advisory firm. In each case, Quuve is deployed as a "site/instance" for each customer. Each site is a fully isolated and secured instance of Quuve.


Quuve is hosted in a cloud virtual hosting which allows us to scale as much as we need and we can have as many nodes as required. The operating system is CentOS Linux. We correctly perform backups, cleanings and maintenance of our sites. We have scripts to automatically create new sites very easily.


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Debris' Quuve - Technologies used

Luc Fabresse
Hi,

Thanks for this email.
It is really nice to read that all these frameworks are used in yet another successful commercial app such as Quuve.

Best,

#Luc

2015-04-15 23:30 GMT+02:00 Cameron Sanders via Pharo-users <[hidden email]>:


---------- Message transféré ----------
From: Cameron Sanders <[hidden email]>
To: Any question about pharo is welcome <[hidden email]>
Cc: 
Date: Wed, 15 Apr 2015 17:30:24 -0400
Subject: Fwd: Debris' Quuve - Technologies used
Several people inquired as to how Quuve was built. Mariano wrote up a nice description of the various tools that were used to build Quuve -- see below. Note also that DebrisPublishing.com website is now up; we are still working on videos, but the site is very lean at present.

-Cam

Quuve Technologies Used


Quuve has been and still is developed with Pharo. We try to use the most up to date stable version of Pharo. Quuve is deployed in GemStone.


Package dependencies are managed via Metacello. Not only do we have many dependencies but also multiple Smalltalk environments: Pharo and GemStone. We also use Metacello to correctly load the needed packages and versions for each of the platforms.


We use Seaside as our web framework and Twitter Bootstrap for Seaside for the layout and design of the app. While some parts are still using the full-request approach, most of the app is done with AJAX and only refreshing the needed part of the screen.


We use JQuery a lot and some external JS libraries such a DataTables (for our table/reports), floatThead, HighCharts (for making charts), TinyMCE (to edit notes and a few other things), etc.


We have a full-featured CRUD system based on Magritte. Actually, we have extended Magritte so much that all our descriptions and components are actually subclasses of the original Magritte classes. We have our own descriptions, components, report column classes, mementos, table layouts, etc. All our framework is Twitter Bootstrap integrated, fully AJAX and with lots of rich features. We can make a full CRUD report/form out of Magritte descriptions in no time.


For persistency we have a library/layer which gives a unified way of saving and querying objects using a Glorp-like interface; it differs in that the where clauses are straight Smalltalk blocks. So far, when we work on Pharo we use Fuel as the "database", while for production we use GemStone. We have developed some compatibility packages so that same code would work in both Smalltalks in the way we expect. Quuve briefly used Oracle’s relational DB for persistence of its securities DB, connecting to it via the Glorp toolkit; because many mature financial DB’s are delivered in relational form, we may need to do so more extensively in the future. Although the need for this may subside as more data becomes available over REST-server interfaces.


We use NeoCSV for parsing CSV, XMLParser, Zinc-REST and STON for providing REST web services, and SIXX for moving data between Pharo and GemStone.


As to the web server, in Pharo we use Zinc, and in GemStone we use nginx + FastCGI. Quuve clients could be for example, an individual or a large advisory firm. In each case, Quuve is deployed as a "site/instance" for each customer. Each site is a fully isolated and secured instance of Quuve.


Quuve is hosted in a cloud virtual hosting which allows us to scale as much as we need and we can have as many nodes as required. The operating system is CentOS Linux. We correctly perform backups, cleanings and maintenance of our sites. We have scripts to automatically create new sites very easily.




Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Debris' Quuve - Technologies used

Brad Selfridge
In reply to this post by Pharo Smalltalk Users mailing list
I'd love to know more about your architecture. It seems like you've built an architecture very similar to what I've dreamed of building. Is there any possibility of asking questions or of you providing examples of some of the features from time to time?

Brad Selfridge
913-269-2385

> On Apr 15, 2015, at 4:30 PM, Cameron Sanders via Pharo-users <[hidden email]> wrote:
>
> <mime-attachment>

Brad Selfridge
Reply | Threaded
Open this post in threaded view
|

Fwd: Fwd: Debris' Quuve - Technologies used

Pharo Smalltalk Users mailing list

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.

-Cam



On Wed, Apr 15, 2015 at 5:59 PM, Brad <[hidden email]> wrote:
I'd love to know more about your architecture. It seems like you've built an architecture very similar to what I've dreamed of building. Is there any possibility of asking questions or of you providing examples of some of the features from time to time?

Brad Selfridge
<a href="tel:913-269-2385" value="+19132692385" target="_blank">913-269-2385

> On Apr 15, 2015, at 4:30 PM, Cameron Sanders via Pharo-users <[hidden email]> wrote:
>
> <mime-attachment>


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Fwd: Debris' Quuve - Technologies used

Yanni Chiu

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

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

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

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?

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

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

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
- biggest collection, typical collection size

Thanks for sharing your experience.


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Debris' Quuve - Technologies used

stepharo
In reply to this post by Pharo Smalltalk Users mailing list
If one day you think that this part can be shared it would be great because it could bring business around your techno

Le 16/4/15 08:10, Cameron Sanders via Pharo-users a écrit :
We have a full-featured CRUD system based on Magritte. Actually, we have extended Magritte so much that all our descriptions and components are actually subclasses of the original Magritte classes. We have our own descriptions, components, report column classes, mementos, table layouts, etc. All our framework is Twitter Bootstrap integrated, fully AJAX and with lots of rich features. We can make a full CRUD report/form out of Magritte descriptions in no time.

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Fwd: Debris' Quuve - Technologies used

Mariano Martinez Peck
In reply to this post by Yanni Chiu
Yanni, please find my answers below.


On Thu, Apr 16, 2015 at 10:57 AM, Mariano Martinez Peck <[hidden email]> wrote:


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.  



--
Reply | Threaded
Open this post in threaded view
|

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

Yanni Chiu
On Apr 16, 2015, at 10:33 AM, Mariano Martinez Peck <[hidden email]> wrote:

> Yanni, please find my answers below.

Mariano, thanks for your detailed answers. Your experience building a CRUD framework using Magritte and Bootstrap was very similar to mine. My stuff is on a back burner for now, but I hope to get back to it sometime soon. I hope Quuve is successful for you guys.


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Debris' Quuve - Technologies used

garduino
In reply to this post by stepharo
+ 10

stepharo wrote
If one day you think that this part can be shared it would be great
because it could bring business around your techno

Le 16/4/15 08:10, Cameron Sanders via Pharo-users a écrit :
> We have a full-featured CRUD system based on Magritte. Actually, we
> have extended Magritte so much that all our descriptions and
> components are actually subclasses of the original Magritte classes.
> We have our own descriptions, components, report column classes,
> mementos, table layouts, etc. All our framework is Twitter Bootstrap
> integrated, fully AJAX and with lots of rich features. We can make a
> full CRUD report/form out of Magritte descriptions in no time.
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Fwd: Debris' Quuve - Technologies used

Stephan Eggermont-3
In reply to this post by Mariano Martinez Peck
On 16/04/15 16:33, Mariano Martinez Peck wrote:
>     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

In QCMagritte we managed to keep most, using an Ajax-Memento and
the chained visitors.

>     3) We want components/descriptions/renderes/etc that better fit our
>     own needs
>     4) We needed more hooks

Definitely.

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

Yep, fully agree.

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Fwd: Debris' Quuve - Technologies used

stepharo
Just a remark

I found strange that not a single little improvements of Magritte was
necessary for the Qude project.
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.

You know that I like business and that people can make money but the
fight is against other community and
competetitor and not within Pharo.

Stef

Le 17/4/15 19:43, Stephan Eggermont a écrit :

> On 16/04/15 16:33, Mariano Martinez Peck wrote:
>>     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
>
> In QCMagritte we managed to keep most, using an Ajax-Memento and
> the chained visitors.
>
>>     3) We want components/descriptions/renderes/etc that better fit our
>>     own needs
>>     4) We needed more hooks
>
> Definitely.
>
>>     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.
>
> Yep, fully agree.
>
> Stephan
>
>
>


Reply | Threaded
Open this post in threaded view
|

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

Yanni Chiu

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


Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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.
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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 <[hidden email]> 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.









--
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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 <[hidden email]> 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.









--

Reply | Threaded
Open this post in threaded view
|

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

Pharo Smalltalk Users mailing list
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.









--


Reply | Threaded
Open this post in threaded view
|

Re: [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 :