Web stack practices (Glorp / QCMagritte)

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

Web stack practices (Glorp / QCMagritte)

laurent laffont
Hi all,

it's been a long time :) At work we are currently comparing several technologies to start a business project that will hopefully be used by thousands of people for several years ;) 

We need a web stack and we put Pharo & co in the comparative process. My team have strong experience in  load-balanced php / mysql deployment that handles millions of records  but we are ready to build on something else though MySQL is still a requirement. 

Thanks for Garage + Glorp, I can prototype things. I wonder how to handle database schema migrations. With our PHP projects we have versionned PHP scripts that are automatically run given a database revision number ( see http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). What are the practices with Glorp ?


We try QCMagritte and we enjoy what we see so far. What are the best practices to glue Magritte and Glorp together ? Especially when you load-balance requests on several images. Some examples ? 

( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable version, MADescriptionBuilder missing. For #development versions of Magritte and QCMagritte, QCConfiguration missing ). So actually I use the one built on CI. )


May be you have some other suggestions on a framework you love ?


Best regards,

Laurent Laffont





Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Esteban A. Maringolo
Laurent,

Regarding QCMagritte I don't know, since I don't use it. I've used
Magritte and Glorp, but didn't bind them, the only special thing I
built for it was an "evented memento" that let me edit a tree of
objects (1:N relations derived from the edited object) within a single
DB transaction.

Regarding migrations I recently found that in VisualWorks Glorp
provides a migration-like strategy, where you define a subclass of a
root Description system, and then can use the diffing to create the
migration.

According to the VW docs, you can do it like this:
sessOld := MyDescriptorSystem new sessionForLogin: aLogin.
sessNew := MyDescriptorSystem01 new sessionForLogin: aLogin.
sessOld system migrateTo: sessNew system.

Such feature is not available in the Pharo port, and migrations are
not automatic, since you need a new class for each migration.
It is something I'd need to play with before porting it to Pharo, if
it's worth it.
Maybe we think about another strategy but still using the DDL objects of Glorp.

Regards!

Esteban A. Maringolo


2017-09-18 7:22 GMT-03:00 laurent <[hidden email]>:

> Hi all,
>
> it's been a long time :) At work we are currently comparing several
> technologies to start a business project that will hopefully be used by
> thousands of people for several years ;)
>
> We need a web stack and we put Pharo & co in the comparative process. My
> team have strong experience in  load-balanced php / mysql deployment that
> handles millions of records  but we are ready to build on something else
> though MySQL is still a requirement.
>
> Thanks for Garage + Glorp, I can prototype things. I wonder how to handle
> database schema migrations. With our PHP projects we have versionned PHP
> scripts that are automatically run given a database revision number ( see
> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). What
> are the practices with Glorp ?
>
>
> We try QCMagritte and we enjoy what we see so far. What are the best
> practices to glue Magritte and Glorp together ? Especially when you
> load-balance requests on several images. Some examples ?
>
> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
> version, MADescriptionBuilder missing. For #development versions of Magritte
> and QCMagritte, QCConfiguration missing ). So actually I use the one built
> on CI. )
>
>
> May be you have some other suggestions on a framework you love ?
>
>
> Best regards,
>
> Laurent Laffont
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

jtuchel
In reply to this post by laurent laffont
Laurent,

I don't have answers to all your questions, but we use Glorp & Seaside
(no Magritte) on VA Smalltalk for our cloud service (http://kontolino.de).



Am 18.09.17 um 12:22 schrieb laurent:

> Hi all,
>
> it's been a long time :) At work we are currently comparing several
> technologies to start a business project that will hopefully be used
> by thousands of people for several years ;)
>
> We need a web stack and we put Pharo & co in the comparative process.
> My team have strong experience in  load-balanced php / mysql
> deployment that handles millions of records  but we are ready to build
> on something else though MySQL is still a requirement.
Sounds interesting.

>
> Thanks for Garage + Glorp, I can prototype things. I wonder how to
> handle database schema migrations. With our PHP projects we have
> versionned PHP scripts that are automatically run given a database
> revision number ( see
> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
> What are the practices with Glorp ?
>
We use a similar approach: our Descriptor class has a method called
schemaVersion, which just returns the current version number. We also
have a "magic" table for settings in our DB, just holding a "name" and a
"value" column, both being Varchars. One of the rows has a name of
"SchemaVersion" and the value is (you guessed it) the printString of the
version number.

Our images accept a few command line paramters, one of them being
--upgradeSchema. It compoares the number in the DB with the one provided
by the descriptor. If they match, the image quits. If not, it calls all
methods named #upgradeSchemaToVersionXXX until it reaches the number in
the Descriptor. Thus we can do both SQL based migrations, like DDL
stuff, as well as Smalltalk object based migrations (which can be sooo
much faster to implement for complex cases). And we have all versioned
and maintained in our beloved Envy repository ;-) .
The rest is just bash script magic (like only starting one image with
the --upgradeSchema parameter and only start the real web workers once
that one has ended succesfully).


About load balancing: You need Sticky sessions, so no failover between
images. If one image crashes, the user must re-logon on a new image.
Works nicely with Apache, I guess nginx works as least as well. For
Apache, look for mod_prox_balancer to learn more.


Hope I could give you a few starting points for your research. And I
also hope you'll find Pharo+Garage+Glorp+QCMagritte a good fit for your
project. We all want success stories ;-)


Joachim

--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1


Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

laurent laffont
Thank you Esteban & Joachim for your answers. 

Laurent


Le lun. 18 sept. 2017 à 14:58, [hidden email] <[hidden email]> a écrit :
Laurent, I don't have answers to all your questions, but we use Glorp & Seaside (no Magritte) on VA Smalltalk for our cloud service (http://kontolino.de). Am 18.09.17 um 12:22 schrieb laurent:
Hi all, it's been a long time :) At work we are currently comparing several technologies to start a business project that will hopefully be used by thousands of people for several years ;) We need a web stack and we put Pharo & co in the comparative process. My team have strong experience in  load-balanced php / mysql deployment that handles millions of records  but we are ready to build on something else though MySQL is still a requirement.
Sounds interesting.
Thanks for Garage + Glorp, I can prototype things. I wonder how to handle database schema migrations. With our PHP projects we have versionned PHP scripts that are automatically run given a database revision number ( see http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). What are the practices with Glorp ?
We use a similar approach: our Descriptor class has a method called schemaVersion, which just returns the current version number. We also have a "magic" table for settings in our DB, just holding a "name" and a "value" column, both being Varchars. One of the rows has a name of "SchemaVersion" and the value is (you guessed it) the printString of the version number. Our images accept a few command line paramters, one of them being --upgradeSchema. It compoares the number in the DB with the one provided by the descriptor. If they match, the image quits. If not, it calls all methods named #upgradeSchemaToVersionXXX until it reaches the number in the Descriptor. Thus we can do both SQL based migrations, like DDL stuff, as well as Smalltalk object based migrations (which can be sooo much faster to implement for complex cases). And we have all versioned and maintained in our beloved Envy repository ;-) . The rest is just bash script magic (like only starting one image with the --upgradeSchema parameter and only start the real web workers once that one has ended succesfully). About load balancing: You need Sticky sessions, so no failover between images. If one image crashes, the user must re-logon on a new image. Works nicely with Apache, I guess nginx works as least as well. For Apache, look for mod_prox_balancer to learn more. Hope I could give you a few starting points for your research. And I also hope you'll find Pharo+Garage+Glorp+QCMagritte a good fit for your project. We all want success stories ;-) Joachim
--
----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] Fliederweg 1                         http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1
Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Stephane Ducasse-3
In reply to this post by laurent laffont
Hi laurent

Let us know how we can help. If necessary we can send our 15 year
experience Java Architect and nearly the same in  Pharo (Esteban) to
meet you at Annecy.

Did you see that Sven released also a native driver for SQL30? I do
not remember.

I do not know if you see but sorabito deploys everything in Pharo and
they mixed also mustache and Seaside.
BTW I know a german company that got a nice and large project for a
large train company and they will use Pharo on the server (plus mobile
apps and others). I can put you in contact also.

Mariano and Quuve used Gemstone + magritte. But this is not the same techno :)

Stef


On Mon, Sep 18, 2017 at 12:22 PM, laurent <[hidden email]> wrote:

> Hi all,
>
> it's been a long time :) At work we are currently comparing several
> technologies to start a business project that will hopefully be used by
> thousands of people for several years ;)
>
> We need a web stack and we put Pharo & co in the comparative process. My
> team have strong experience in  load-balanced php / mysql deployment that
> handles millions of records  but we are ready to build on something else
> though MySQL is still a requirement.
>
> Thanks for Garage + Glorp, I can prototype things. I wonder how to handle
> database schema migrations. With our PHP projects we have versionned PHP
> scripts that are automatically run given a database revision number ( see
> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). What
> are the practices with Glorp ?
>
>
> We try QCMagritte and we enjoy what we see so far. What are the best
> practices to glue Magritte and Glorp together ? Especially when you
> load-balance requests on several images. Some examples ?
>
> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
> version, MADescriptionBuilder missing. For #development versions of Magritte
> and QCMagritte, QCConfiguration missing ). So actually I use the one built
> on CI. )
>
>
> May be you have some other suggestions on a framework you love ?
>
>
> Best regards,
>
> Laurent Laffont
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Richard Sargent
Administrator
In reply to this post by laurent laffont
laurent laffont wrote
> Hi all,
>
> it's been a long time :) At work we are currently comparing several
> technologies to start a business project that will hopefully be used by
> thousands of people for several years ;)

Laurent, I realize you are asking this on the Pharo list, looking for a
Pharo-specific answer. You should also post your requirements on the GLASS
list (http://forum.world.st/GLASS-f1460844.html). A number of
people/businesses there use a /develop on Pharo, deploy on GemStone
approach/. They will be able to give you some good advice on using
GemStone/S for your database.



> We need a web stack and we put Pharo & co in the comparative process.
> My team have strong experience in  load-balanced php / mysql deployment
> that handles millions of records  but we are ready to build on
> something else though MySQL is still a requirement.
>
> Thanks for Garage + Glorp, I can prototype things. I wonder how to
> handle database schema migrations. With our PHP projects we have
> versionned PHP scripts that are automatically run given a database
> revision number ( see
> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
> What are the practices with Glorp ?
>
>
> We try QCMagritte and we enjoy what we see so far. What are the best
> practices to glue Magritte and Glorp together ? Especially when you
> load-balance requests on several images. Some examples ?
>
> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
> version, MADescriptionBuilder missing. For #development versions of
> Magritte and QCMagritte, QCConfiguration missing ). So actually I use
> the one built on CI. )
>
>
> May be you have some other suggestions on a framework you love ?
>
>
> Best regards,
>
> Laurent Laffont





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Stephan Eggermont-3
In reply to this post by laurent laffont
On 18-09-17 12:22, laurent wrote:
> We try QCMagritte and we enjoy what we see so far. What are the best
> practices to glue Magritte and Glorp together ? Especially when you
> load-balance requests on several images. Some examples ?
>
> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
> version, MADescriptionBuilder missing. For #development versions of
> Magritte and QCMagritte, QCConfiguration missing ). So actually I use
> the one built on CI. )

I really like describing domain objects with Magritte and using chains
of visitors to add cross-cutting concerns like translations, styling and
access control. The resulting domain code is very clean and DRY. To map
to database/Glorp I would just add properties to the description
wherever needed, and add a visitor creating the mappings. We didn't need
that as we developed in Pharo and deployed on Gemstone.

At the moment QC generates applications using jQuery, and the live
updating needs a round-trip to the server. You might want to substitute
that with something that does more client side. I haven't looked in
detail at what Johan Brichau is doing.

An open issue is live updates that update each other. That needs
automatically calculating dependencies and update order.

I've copied the latest configuration and added #'pharo6.x' but that is
not enough.

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

laurent laffont
In reply to this post by Richard Sargent
Hi Richard,


Laurent, I realize you are asking this on the Pharo list, looking for a Pharo-specific answer. You should also post your requirements on the GLASS list (http://forum.world.st/GLASS-f1460844.html). A number of people/businesses there use a /develop on Pharo, deploy on GemStone approach/. They will be able to give you some good advice on using GemStone/S for your database.


My team build free (AGPL) software and we require a full open stack. I've read several testimonials about Gemstone qualities, nevertheless  it could not be an option for this project.

Regards,

Laurent


We need a web stack and we put Pharo & co in the comparative process. My team have strong experience in load-balanced php / mysql deployment that handles millions of records but we are ready to build on something else though MySQL is still a requirement. Thanks for Garage + Glorp, I can prototype things. I wonder how to handle database schema migrations. With our PHP projects we have versionned PHP scripts that are automatically run given a database revision number ( see http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). What are the practices with Glorp ? We try QCMagritte and we enjoy what we see so far. What are the best practices to glue Magritte and Glorp together ? Especially when you load-balance requests on several images. Some examples ? ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable version, MADescriptionBuilder missing. For #development versions of Magritte and QCMagritte, QCConfiguration missing ). So actually I use the one built on CI. ) May be you have some other suggestions on a framework you love ? Best regards, Laurent Laffont
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

laurent laffont
In reply to this post by Stephan Eggermont-3
Hi Stephan,

actually the difficult part is how to manage correctly Glorp sessions/connections and update of objects in database. My team is quite sad because QCMagritte and Glorp looks nice but we lack experience glueing both together and could not find any documentation on the subject.

Laurent

Le mer. 20 sept. 2017 à 11:53, stephan <[hidden email]> a écrit :
On 18-09-17 12:22, laurent wrote:
We try QCMagritte and we enjoy what we see so far. What are the best practices to glue Magritte and Glorp together ? Especially when you load-balance requests on several images. Some examples ? ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable version, MADescriptionBuilder missing. For #development versions of Magritte and QCMagritte, QCConfiguration missing ). So actually I use the one built on CI. )
I really like describing domain objects with Magritte and using chains of visitors to add cross-cutting concerns like translations, styling and access control. The resulting domain code is very clean and DRY. To map to database/Glorp I would just add properties to the description wherever needed, and add a visitor creating the mappings. We didn't need that as we developed in Pharo and deployed on Gemstone. At the moment QC generates applications using jQuery, and the live updating needs a round-trip to the server. You might want to substitute that with something that does more client side. I haven't looked in detail at what Johan Brichau is doing. An open issue is live updates that update each other. That needs automatically calculating dependencies and update order. I've copied the latest configuration and added #'pharo6.x' but that is not enough. Stephan
Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

DiegoLont
Hi Laurent,

I am happy that you like QCMagritte. I wrote quite some parts of it, but it also has been a while since I last used it. I try to support it in my spare time, so I will look into the issue that prevents it from loading into pharo 6.

Here some ideas that I think of,

QCMagritte is a stack based on Seaside and Magritte. So you have a choice wether you connect Glorp to the session management of Seaside (like Gemstone does, I do not know exactly) or to the update mechanism of Magritte.

This updating of the object is done in the memento. You can give your objects a custom memento class and override here the pull // push methods that update your model. It actually has a commit method that commits the changes into the object.

Note the QCMagritte already has a custom memento class, for the AJAX liveness, so I suggest subclassing QCAjaxMemento.

Of course, you need to do something in case of a changed object, since you plan on running multiple images, so perhaps on validating the object (also controlled by the memento), you want to give some error messages, forcing the user to reload before committing his changes.

I do not know if implementing this into the memento’s gives you proper performance, as potentially multiple objects are updated by one user action.

Regards,
Diego

On 22 Sep 2017, at 10:28, laurent <[hidden email]> wrote:

Hi Stephan,

actually the difficult part is how to manage correctly Glorp sessions/connections and update of objects in database. My team is quite sad because QCMagritte and Glorp looks nice but we lack experience glueing both together and could not find any documentation on the subject.

Laurent

Le mer. 20 sept. 2017 à 11:53, stephan <[hidden email]> a écrit :
On 18-09-17 12:22, laurent wrote:
We try QCMagritte and we enjoy what we see so far. What are the best practices to glue Magritte and Glorp together ? Especially when you load-balance requests on several images. Some examples ? ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable version, MADescriptionBuilder missing. For #development versions of Magritte and QCMagritte, QCConfiguration missing ). So actually I use the one built on CI. )
I really like describing domain objects with Magritte and using chains of visitors to add cross-cutting concerns like translations, styling and access control. The resulting domain code is very clean and DRY. To map to database/Glorp I would just add properties to the description wherever needed, and add a visitor creating the mappings. We didn't need that as we developed in Pharo and deployed on Gemstone. At the moment QC generates applications using jQuery, and the live updating needs a round-trip to the server. You might want to substitute that with something that does more client side. I haven't looked in detail at what Johan Brichau is doing. An open issue is live updates that update each other. That needs automatically calculating dependencies and update order. I've copied the latest configuration and added #'pharo6.x' but that is not enough. Stephan

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Hannes Hirzel
Hello Diego


What does QC in QCMagritte stand for?

I understand that QCMagritte is an application framework on top of
Seaside and Magritte.

I found this presentation

    https://www.slideshare.net/esug/getting-started-with-qcmagritte

Is there a home page with more information?

Regards
Hannes





On 9/22/17, Diego Lont <[hidden email]> wrote:

> Hi Laurent,
>
> I am happy that you like QCMagritte. I wrote quite some parts of it, but it
> also has been a while since I last used it. I try to support it in my spare
> time, so I will look into the issue that prevents it from loading into pharo
> 6.
>
> Here some ideas that I think of,
>
> QCMagritte is a stack based on Seaside and Magritte. So you have a choice
> wether you connect Glorp to the session management of Seaside (like Gemstone
> does, I do not know exactly) or to the update mechanism of Magritte.
>
> This updating of the object is done in the memento. You can give your
> objects a custom memento class and override here the pull // push methods
> that update your model. It actually has a commit method that commits the
> changes into the object.
>
> Note the QCMagritte already has a custom memento class, for the AJAX
> liveness, so I suggest subclassing QCAjaxMemento.
>
> Of course, you need to do something in case of a changed object, since you
> plan on running multiple images, so perhaps on validating the object (also
> controlled by the memento), you want to give some error messages, forcing
> the user to reload before committing his changes.
>
> I do not know if implementing this into the memento’s gives you proper
> performance, as potentially multiple objects are updated by one user
> action.
>
> Regards,
> Diego
>
>> On 22 Sep 2017, at 10:28, laurent <[hidden email]> wrote:
>>
>> Hi Stephan,
>>
>> actually the difficult part is how to manage correctly Glorp
>> sessions/connections and update of objects in database. My team is quite
>> sad because QCMagritte and Glorp looks nice but we lack experience glueing
>> both together and could not find any documentation on the subject.
>>
>> Laurent
>>
>> Le mer. 20 sept. 2017 à 11:53, stephan <[hidden email]> a écrit :
>>> On 18-09-17 12:22, laurent wrote:
>>> We try QCMagritte and we enjoy what we see so far. What are the best
>>> practices to glue Magritte and Glorp together ? Especially when you
>>> load-balance requests on several images. Some examples ?
>>>
>>> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
>>> version, MADescriptionBuilder missing. For #development versions of
>>> Magritte and QCMagritte, QCConfiguration missing ). So actually I use the
>>> one built on CI. )
>>>
>>> I really like describing domain objects with Magritte and using chains of
>>> visitors to add cross-cutting concerns like translations, styling and
>>> access control. The resulting domain code is very clean and DRY. To map
>>> to database/Glorp I would just add properties to the description wherever
>>> needed, and add a visitor creating the mappings. We didn't need that as
>>> we developed in Pharo and deployed on Gemstone.
>>>
>>> At the moment QC generates applications using jQuery, and the live
>>> updating needs a round-trip to the server. You might want to substitute
>>> that with something that does more client side. I haven't looked in
>>> detail at what Johan Brichau is doing.
>>>
>>> An open issue is live updates that update each other. That needs
>>> automatically calculating dependencies and update order.
>>>
>>> I've copied the latest configuration and added #'pharo6.x' but that is
>>> not enough.
>>>
>>> Stephan
>>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Hannes Hirzel
In reply to this post by laurent laffont
On 9/18/17, laurent <[hidden email]> wrote:

> Hi all,
>
> it's been a long time :) At work we are currently comparing several
> technologies to start a business project that will hopefully be used by
> thousands of people for several years ;)
>
> We need a web stack and we put Pharo & co in the comparative process.
> My team have strong experience in  load-balanced php / mysql deployment
> that handles millions of records  but we are ready to build on
> something else though MySQL is still a requirement.
>
> Thanks for Garage + Glorp, I can prototype things. I wonder how to
> handle database schema migrations. With our PHP projects we have
> versionned PHP scripts that are automatically run given a database
> revision number ( see
> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
> What are the practices with Glorp ?
>
>
> We try QCMagritte and we enjoy what we see so far. What are the best
> practices to glue Magritte and Glorp together ? Especially when you
> load-balance requests on several images. Some examples ?
>
> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
> version, MADescriptionBuilder missing. For #development versions of
> Magritte and QCMagritte, QCConfiguration missing ). So actually I use
> the one built on CI. )
>
>
> May be you have some other suggestions on a framework you love ?

Maybe you have a look as well at
https://railsexpress.quora.com/Pharo-Seaside-Express
(referenced in another thread).

Use Smalltalk as modeling  / design tool and generator. Then the run
time is done with another technology.

>
> Best regards,
>
> Laurent Laffont
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

DiegoLont
There is actually a tutorial included in the framework itself. One you have it loaded, you can start the webpage to localhost:8080 and there you have your tutorial. But this tutorial should be on a external webpage … one of the things on my todo list.

On 22 Sep 2017, at 12:55, H. Hirzel <[hidden email]> wrote:

On 9/18/17, laurent <[hidden email]> wrote:
Hi all,

it's been a long time :) At work we are currently comparing several
technologies to start a business project that will hopefully be used by
thousands of people for several years ;)

We need a web stack and we put Pharo & co in the comparative process.
My team have strong experience in  load-balanced php / mysql deployment
that handles millions of records  but we are ready to build on
something else though MySQL is still a requirement.

Thanks for Garage + Glorp, I can prototype things. I wonder how to
handle database schema migrations. With our PHP projects we have
versionned PHP scripts that are automatically run given a database
revision number ( see
http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
What are the practices with Glorp ?


We try QCMagritte and we enjoy what we see so far. What are the best
practices to glue Magritte and Glorp together ? Especially when you
load-balance requests on several images. Some examples ?

( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
version, MADescriptionBuilder missing. For #development versions of
Magritte and QCMagritte, QCConfiguration missing ). So actually I use
the one built on CI. )


May be you have some other suggestions on a framework you love ?

Maybe you have a look as well at
https://railsexpress.quora.com/Pharo-Seaside-Express
(referenced in another thread).

Use Smalltalk as modeling  / design tool and generator. Then the run
time is done with another technology.


Best regards,

Laurent Laffont

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Hannes Hirzel
On 9/22/17, Diego Lont <[hidden email]> wrote:
> There is actually a tutorial included in the framework itself.

Great!

>One you have
> it loaded, you can start the webpage to localhost:8080 and there you have
> your tutorial. But this tutorial should be on a external webpage … one of
> the things on my todo list.

No problem if the tutorial is included in the framework. I just need to know.

Where is the repository of QCMagritte?


>> On 22 Sep 2017, at 12:55, H. Hirzel <[hidden email]> wrote:
>>
>> On 9/18/17, laurent <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>> Hi all,
>>>
>>> it's been a long time :) At work we are currently comparing several
>>> technologies to start a business project that will hopefully be used by
>>> thousands of people for several years ;)
>>>
>>> We need a web stack and we put Pharo & co in the comparative process.
>>> My team have strong experience in  load-balanced php / mysql deployment
>>> that handles millions of records  but we are ready to build on
>>> something else though MySQL is still a requirement.
>>>
>>> Thanks for Garage + Glorp, I can prototype things. I wonder how to
>>> handle database schema migrations. With our PHP projects we have
>>> versionned PHP scripts that are automatically run given a database
>>> revision number ( see
>>> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
>>> What are the practices with Glorp ?
>>>
>>>
>>> We try QCMagritte and we enjoy what we see so far. What are the best
>>> practices to glue Magritte and Glorp together ? Especially when you
>>> load-balance requests on several images. Some examples ?
>>>
>>> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
>>> version, MADescriptionBuilder missing. For #development versions of
>>> Magritte and QCMagritte, QCConfiguration missing ). So actually I use
>>> the one built on CI. )
>>>
>>>
>>> May be you have some other suggestions on a framework you love ?
>>
>> Maybe you have a look as well at
>> https://railsexpress.quora.com/Pharo-Seaside-Express
>> <https://railsexpress.quora.com/Pharo-Seaside-Express>
>> (referenced in another thread).
>>
>> Use Smalltalk as modeling  / design tool and generator. Then the run
>> time is done with another technology.
>>
>>>
>>> Best regards,
>>>
>>> Laurent Laffont
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

DiegoLont
The repository can be found on smalltalk hub. Here are also load instruction:


I just checked loading in pharo 6 (after making a fix) of:
Gofer new url: 'http://smalltalkhub.com/mc/DiegoLont/QCMagritte/main'; package: 'ConfigurationOfQCMagritte'; load.

((Smalltalk at: #ConfigurationOfQCMagritte) project version: #'development') load.

(Smalltalk at: #ZnZincServerAdaptor) startOn: 8080

And this allows me to start the tutorial. It seems not all versions load yet, so I need to do some more work on the configuration, but this will be next week.

Regards,
Diego

P.S. QC stands for the company it was originally build for. I do not know exactly where the initials stand for … as it was already an historic name at that time.


On 22 Sep 2017, at 13:35, H. Hirzel <[hidden email]> wrote:

On 9/22/17, Diego Lont <[hidden email]> wrote:
There is actually a tutorial included in the framework itself.

Great!

One you have
it loaded, you can start the webpage to localhost:8080 and there you have
your tutorial. But this tutorial should be on a external webpage … one of
the things on my todo list.

No problem if the tutorial is included in the framework. I just need to know.

Where is the repository of QCMagritte?


On 22 Sep 2017, at 12:55, H. Hirzel <[hidden email]> wrote:

On 9/18/17, laurent <[hidden email]
<[hidden email]>> wrote:
Hi all,

it's been a long time :) At work we are currently comparing several
technologies to start a business project that will hopefully be used by
thousands of people for several years ;)

We need a web stack and we put Pharo & co in the comparative process.
My team have strong experience in  load-balanced php / mysql deployment
that handles millions of records  but we are ready to build on
something else though MySQL is still a requirement.

Thanks for Garage + Glorp, I can prototype things. I wonder how to
handle database schema migrations. With our PHP projects we have
versionned PHP scripts that are automatically run given a database
revision number ( see
http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
What are the practices with Glorp ?


We try QCMagritte and we enjoy what we see so far. What are the best
practices to glue Magritte and Glorp together ? Especially when you
load-balance requests on several images. Some examples ?

( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
version, MADescriptionBuilder missing. For #development versions of
Magritte and QCMagritte, QCConfiguration missing ). So actually I use
the one built on CI. )


May be you have some other suggestions on a framework you love ?

Maybe you have a look as well at
https://railsexpress.quora.com/Pharo-Seaside-Express
<https://railsexpress.quora.com/Pharo-Seaside-Express>
(referenced in another thread).

Use Smalltalk as modeling  / design tool and generator. Then the run
time is done with another technology.


Best regards,

Laurent Laffont

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Stephane Ducasse-3
In reply to this post by laurent laffont
Laurent

do you need that we send someone to your place to help?

Stef

On Fri, Sep 22, 2017 at 10:28 AM, laurent <[hidden email]> wrote:

> Hi Stephan,
>
> actually the difficult part is how to manage correctly Glorp
> sessions/connections and update of objects in database. My team is quite sad
> because QCMagritte and Glorp looks nice but we lack experience glueing both
> together and could not find any documentation on the subject.
>
> Laurent
>
>
> Le mer. 20 sept. 2017 à 11:53, stephan <[hidden email]> a écrit :
>
> On 18-09-17 12:22, laurent wrote:
>
> We try QCMagritte and we enjoy what we see so far. What are the best
> practices to glue Magritte and Glorp together ? Especially when you
> load-balance requests on several images. Some examples ? ( FYI, I cannot
> load QCMagritte in a fresh Pharo 6 image ( for #stable version,
> MADescriptionBuilder missing. For #development versions of Magritte and
> QCMagritte, QCConfiguration missing ). So actually I use the one built on
> CI. )
>
> I really like describing domain objects with Magritte and using chains of
> visitors to add cross-cutting concerns like translations, styling and access
> control. The resulting domain code is very clean and DRY. To map to
> database/Glorp I would just add properties to the description wherever
> needed, and add a visitor creating the mappings. We didn't need that as we
> developed in Pharo and deployed on Gemstone. At the moment QC generates
> applications using jQuery, and the live updating needs a round-trip to the
> server. You might want to substitute that with something that does more
> client side. I haven't looked in detail at what Johan Brichau is doing. An
> open issue is live updates that update each other. That needs automatically
> calculating dependencies and update order. I've copied the latest
> configuration and added #'pharo6.x' but that is not enough. Stephan

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Stephane Ducasse-3
In reply to this post by DiegoLont
Diego

I recently restarted to edit a booklet for Magritte. It would be nice
if we can join forces.
https://github.com/SquareBracketAssociates/Booklet-Magritte

On Fri, Sep 22, 2017 at 1:27 PM, Diego Lont <[hidden email]> wrote:

> There is actually a tutorial included in the framework itself. One you have
> it loaded, you can start the webpage to localhost:8080 and there you have
> your tutorial. But this tutorial should be on a external webpage … one of
> the things on my todo list.
>
> On 22 Sep 2017, at 12:55, H. Hirzel <[hidden email]> wrote:
>
> On 9/18/17, laurent <[hidden email]> wrote:
>
> Hi all,
>
> it's been a long time :) At work we are currently comparing several
> technologies to start a business project that will hopefully be used by
> thousands of people for several years ;)
>
> We need a web stack and we put Pharo & co in the comparative process.
> My team have strong experience in  load-balanced php / mysql deployment
> that handles millions of records  but we are ready to build on
> something else though MySQL is still a requirement.
>
> Thanks for Garage + Glorp, I can prototype things. I wonder how to
> handle database schema migrations. With our PHP projects we have
> versionned PHP scripts that are automatically run given a database
> revision number ( see
> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
> What are the practices with Glorp ?
>
>
> We try QCMagritte and we enjoy what we see so far. What are the best
> practices to glue Magritte and Glorp together ? Especially when you
> load-balance requests on several images. Some examples ?
>
> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
> version, MADescriptionBuilder missing. For #development versions of
> Magritte and QCMagritte, QCConfiguration missing ). So actually I use
> the one built on CI. )
>
>
> May be you have some other suggestions on a framework you love ?
>
>
> Maybe you have a look as well at
> https://railsexpress.quora.com/Pharo-Seaside-Express
> (referenced in another thread).
>
> Use Smalltalk as modeling  / design tool and generator. Then the run
> time is done with another technology.
>
>
> Best regards,
>
> Laurent Laffont
>
>

magritte-wip.pdf (2M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Stephane Ducasse-3
Laurent

just for the record, back in 2008-9 the largest web app in south
america in terms of users has been developed by extending
Magritte and done by Esteban (the business model was bad and it died
but not for technical reason).

Stef

On Fri, Sep 22, 2017 at 6:21 PM, Stephane Ducasse
<[hidden email]> wrote:

> Diego
>
> I recently restarted to edit a booklet for Magritte. It would be nice
> if we can join forces.
> https://github.com/SquareBracketAssociates/Booklet-Magritte
>
> On Fri, Sep 22, 2017 at 1:27 PM, Diego Lont <[hidden email]> wrote:
>> There is actually a tutorial included in the framework itself. One you have
>> it loaded, you can start the webpage to localhost:8080 and there you have
>> your tutorial. But this tutorial should be on a external webpage … one of
>> the things on my todo list.
>>
>> On 22 Sep 2017, at 12:55, H. Hirzel <[hidden email]> wrote:
>>
>> On 9/18/17, laurent <[hidden email]> wrote:
>>
>> Hi all,
>>
>> it's been a long time :) At work we are currently comparing several
>> technologies to start a business project that will hopefully be used by
>> thousands of people for several years ;)
>>
>> We need a web stack and we put Pharo & co in the comparative process.
>> My team have strong experience in  load-balanced php / mysql deployment
>> that handles millions of records  but we are ready to build on
>> something else though MySQL is still a requirement.
>>
>> Thanks for Garage + Glorp, I can prototype things. I wonder how to
>> handle database schema migrations. With our PHP projects we have
>> versionned PHP scripts that are automatically run given a database
>> revision number ( see
>> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
>> What are the practices with Glorp ?
>>
>>
>> We try QCMagritte and we enjoy what we see so far. What are the best
>> practices to glue Magritte and Glorp together ? Especially when you
>> load-balance requests on several images. Some examples ?
>>
>> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
>> version, MADescriptionBuilder missing. For #development versions of
>> Magritte and QCMagritte, QCConfiguration missing ). So actually I use
>> the one built on CI. )
>>
>>
>> May be you have some other suggestions on a framework you love ?
>>
>>
>> Maybe you have a look as well at
>> https://railsexpress.quora.com/Pharo-Seaside-Express
>> (referenced in another thread).
>>
>> Use Smalltalk as modeling  / design tool and generator. Then the run
>> time is done with another technology.
>>
>>
>> Best regards,
>>
>> Laurent Laffont
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

laurent laffont
In reply to this post by Stephane Ducasse-3
Thanks Stef, it would be nice, nevertheless I don't think the boss will pay a consultant :(

Laurent

Le 22 septembre 2017 18:18:32 GMT+02:00, Stephane Ducasse <[hidden email]> a écrit :
Laurent

do you need that we send someone to your place to help?

Stef

On Fri, Sep 22, 2017 at 10:28 AM, laurent <[hidden email]> wrote:
Hi Stephan,

actually the difficult part is how to manage correctly Glorp
sessions/connections and update of objects in database. My team is quite sad
because QCMagritte and Glorp looks nice but we lack experience glueing both
together and could not find any documentation on the subject.

Laurent


Le mer. 20 sept. 2017 à 11:53, stephan <[hidden email]> a écrit :

On 18-09-17 12:22, laurent wrote:

We try QCMagritte and we enjoy what we see so far. What are the best
practices to glue Magritte and Glorp together ? Especially when you
load-balance requests on several images. Some examples ? ( FYI, I cannot
load QCMagritte in a fresh Pharo 6 image ( for #stable version,
MADescriptionBuilder missing. For #development versions of Magritte and
QCMagritte, QCConfiguration missing ). So actually I use the one built on
CI. )

I really like describing domain objects with Magritte and using chains of
visitors to add cross-cutting concerns like translations, styling and access
control. The resulting domain code is very clean and DRY. To map to
database/Glorp I would just add properties to the description wherever
needed, and add a visitor creating the mappings. We didn't need that as we
developed in Pharo and deployed on Gemstone. At the moment QC generates
applications using jQuery, and the live updating needs a round-trip to the
server. You might want to substitute that with something that does more
client side. I haven't looked in detail at what Johan Brichau is doing. An
open issue is live updates that update each other. That needs automatically
calculating dependencies and update order. I've copied the latest
configuration and added #'pharo6.x' but that is not enough. Stephan

Reply | Threaded
Open this post in threaded view
|

Re: Web stack practices (Glorp / QCMagritte)

Stephane Ducasse-3
So if the consortium makes an effort and support the cost would it help.
Or is it for nothing?
What if you come to visit us?

Stef

On Sat, Sep 23, 2017 at 3:37 PM, Laurent Laffont
<[hidden email]> wrote:

> Thanks Stef, it would be nice, nevertheless I don't think the boss will pay
> a consultant :(
>
> Laurent
>
>
> Le 22 septembre 2017 18:18:32 GMT+02:00, Stephane Ducasse
> <[hidden email]> a écrit :
>>
>> Laurent
>>
>> do you need that we send someone to your place to help?
>>
>> Stef
>>
>> On Fri, Sep 22, 2017 at 10:28 AM, laurent <[hidden email]>
>> wrote:
>>>
>>>  Hi Stephan,
>>>
>>>  actually the difficult part is how to manage correctly Glorp
>>>  sessions/connections and update of objects in database. My team is quite
>>> sad
>>>  because QCMagritte and Glorp looks nice but we lack experience glueing
>>> both
>>>  together and could not find any documentation on the subject.
>>>
>>>  Laurent
>>>
>>>
>>>  Le mer. 20 sept. 2017 à 11:53, stephan <[hidden email]> a écrit :
>>>
>>>  On 18-09-17 12:22, laurent wrote:
>>>
>>>  We try QCMagritte and we enjoy what we see so far. What are the best
>>>  practices to glue Magritte and Glorp together ? Especially when you
>>>  load-balance requests on several images. Some examples ? ( FYI, I cannot
>>>  load QCMagritte in a fresh Pharo 6 image ( for #stable version,
>>>  MADescriptionBuilder missing. For #development versions of Magritte and
>>>  QCMagritte, QCConfiguration missing ). So actually I use the one built
>>> on
>>>  CI. )
>>>
>>>  I really like describing domain objects with Magritte and using chains
>>> of
>>>  visitors to add cross-cutting concerns like translations, styling and
>>> access
>>>  control. The resulting domain code is very clean and DRY. To map to
>>>  database/Glorp I would just add properties to the description wherever
>>>  needed, and add a visitor creating the mappings. We didn't need that as
>>> we
>>>  developed in Pharo and deployed on Gemstone. At the moment QC generates
>>>  applications using jQuery, and the live updating needs a round-trip to
>>> the
>>>  server. You might want to substitute that with something that does more
>>>  client side. I haven't looked in detail at what Johan Brichau is doing.
>>> An
>>>  open issue is live updates that update each other. That needs
>>> automatically
>>>  calculating dependencies and update order. I've copied the latest
>>>  configuration and added #'pharo6.x' but that is not enough. Stephan
>>
>>
>