Re: [Pharo-users] Why do I not see the transactions when opening a customer

[Diego Lont]

Hi Jupiter.

This is always a hard problem, as you state: you want a customer to change 
their own password, and also want a customer to be allowed to set a password 
that he has lost. You could of course make your server code more resilient, and 
demand there is security information provided when changing a password.

I.E.
newPassword: aString authentication: anAuthenticationInformation
“ and here you need to verify the authentication information being:
1. user / password of the user that has the account
2. user / password of an administration
3. reset information sent to the user
“
… details can very, but as said: there will always be a back door.

So if it is really important, one should implement strong authentication. 
Strong authentication is based on the fact, that a user not only knows 
something, but also has something. That is why banks always use things such as 
a “rabo scanner” that you need to insert your bank pass (something you have), 
type your pin (something you know) and input a picture / code and the result is 
a new code that you enter.


> On 19 Aug 2019, at 10:01, Jupiter Jones  wrote:
> 
> Hi Deigo,
> 
> Apologies Roelof for jumping in to your thread. :)
> 
> This solves the issue of storing passwords, however, Richard made the case 
> for malevolent or broken code…
> 
>>>>>  - you not only provide a getter for the
>>>>>password, but a setter!  This means that
>>>>>malevolent/broken code can do
>>>>>  aBankAccount password: 'PWNED!'.
>>>>>and then supply the new password 'PWNED!'
>>>>>whenever a password is needed.
>>>>>  > The password must be supplied when a
>>>>>BankAccount is changed and it should not
>>>>>be settable afterwards (except perhaps with
>>>>>a master key).
> 
> To scale there is likely the need to allow customers to change their own 
> password without call centre or administrator intervention.
> 
> Do you know of any implementations of user/password stores that are resilient 
> to malevolent or broken code?
> 
> Cheers,
> 
> J
> 
>> On 19 Aug 2019, at 5:40 pm, Diego Lont > <mailto:diego.l...@delware.nl>> wrote:
>> 
>> The best way to implement a password security is to never store the 
>> password, but only a hashed password. This way, you never can have a 
>> security leak for your passwords: because you don’t have them. And for 
>> hashing you use a standard modern hashing algorithm, so it cannot be easily 
>> rolled back. What I often use is that I make the username readonly, and make 
>> the hash depend on the username (i.e. use the username as seed)
>> 
>> So you implement
>> password: aString
>>  self hashedPassword: (self hash: aString)
>> 
>> verifyPassword: aString
>>  ^(self hash: aString) = self hashedPassword
>> 
>> Regards,
>> Diego
> 

Re: [Pharo-users] Why do I not see the transactions when opening a customer

[Diego Lont]

The best way to implement a password security is to never store the password, 
but only a hashed password. This way, you never can have a security leak for 
your passwords: because you don’t have them. And for hashing you use a standard 
modern hashing algorithm, so it cannot be easily rolled back. What I often use 
is that I make the username readonly, and make the hash depend on the username 
(i.e. use the username as seed)

So you implement
password: aString
self hashedPassword: (self hash: aString)

verifyPassword: aString
^(self hash: aString) = self hashedPassword

Regards,
Diego

> On 18 Aug 2019, at 18:23, Roelof Wobben  wrote:
> 
> Thanks, 
> 
> I implement almost everything now.
> 
> But I fail to see how to make for password a private variable without getters 
> and setters
> and still  have different password for every bankaccount and can test against 
> it.
> 
> So please help.
> 
> Roelof
> 
> 
> 
> Op 17-8-2019 om 12:48 schreef Roelof Wobben:
>> Op 17-8-2019 om 12:33 schreef Richard O'Keefe:
>>> Good-oh.
>>> Looking at Bankaccounts
>>>  - the name should be singular, not plural
>>>  - Smalltalk uses baStudlyCaps
>>>  > Call it BankAccount.
>>> 
>>>  - you not only provide a getter for the
>>>password, but a setter!  This means that
>>>malevolent/broken code can do
>>>  aBankAccount password: 'PWNED!'.
>>>and then supply the new password 'PWNED!'
>>>whenever a password is needed.
>>>  > The password must be supplied when a
>>>BankAccount is changed and it should not
>>>be settable afterwards (except perhaps with
>>>a master key).
>>> 
>> 
>> Thanks all changed.
>> 
>>>  - #addToBankAccount: is an unhelpful name; we
>>>know it's adding to a BankAccount because that
>>>is where it is.  But what is it adding?
>>>(Hint: an account might have more than one
>>>customer in the real world, so we might need
>>>to distinguish between #addCustomer: and)
>>>  > #addTransaction: , which would be a better name.
>>> 
>> 
>> the method adds a bankaccount to the bankAccounts collection  so maybe 
>> AddBankAccountToBankAccountsOfCustomer ? 
>> 
>>>  - There is a missing method.  When you ask a bank
>>>account to report a secret, *it* should check
>>>the password.
>>>  > add
>>> queryBalance: pwd
>>>   ^password = pwd
>>>  ifTrue:  [transactions detectSum: [:each | each amount]]
>>>  ifFalse: [self error: 'wrong password']
>>> 
>> 
>> I know its missing. That is the part I still have to figure out.How can I 
>> make a collection of all transactions split by account and then the total of 
>> it. 
>> 
>> 
>>> Transactions
>>>  - This too should be singular, not plural.
>>>  > Rename it to Transaction.
>>> 
>>>  - You know it is unfinished.
>>> 
>> 
>> 
>> Changed the name and what is missing here then. 
>> 
>> 
>>> Customer
>>>  - You know it is unfinished.
>>> 
>> 
>> What is then missing here. 
>> 
>>>  - Smalltalk uses baStudlyCaps style.  The instance
>>>variable 'bankaccounts' is two words run together.
>>>  > Change it to 'bankAccounts'.
>>> 
>>>  - The very first method has two style issues and a major flaw.
>>>AddBankAccountToCustomer: bankaccount [
>>>  bankaccounts add: bankaccounts
>>>]
>>>  - Style flaw one: method names are expected to begin
>>>with a lower case letter, not a capital.  (That's C#.)
>>>  - Style flaw two; we *knew* it's adding to a customer,
>>>because that's where it is.
>>>  > Rename to #addBankAccount:
>>> 
>>>  - The major flaw is that the argument 'bankaccount' is
>>>ignored, while the 'bankaccounts' collection is added
>>>TO ITSELF.  This is one of the rare occasions when a
>>>type checker would have caught a mistake.
>>>  > Revise to
>>>addBankAccount:aBankAccount [
>>>  bankAccounts addLast: aBankAccount.
>>>]
>>> 
>>>  - You have a setter, #bankaccounts:.  WHY?  This should be
>>>a completely private variable, initialised when the
>>>Customer object is created, and never reassigned thereafter.
>>>  > Delete that setter.
>>> 
>>> 
>>  Done and Done. 
>> 
>> 
>>> Customer >> AddBankAccountToCustomer: bankaccount [ 
>>>bankaccounts  add:  bankaccounts.
>>> 
>>> ]
>>> 
>>> On Sat, 17 Aug 2019 at 21:59, Roelof Wobben >> > wrote:
>>> Sorry, then a pointed to a wrong repo
>>> this is the  repo with smalltalk code : 
>>> 
>>> https://github.com/rwobben/banking 
>>> 
>>> Roelof
>>> 
>>> 
>>> 
>>> Op 17-8-2019 om 11:25 schreef Richard O'Keefe:
 https://github.com/rwobben/bankaccount 
 
 points to a repository with C# code, so I cannot comment on the Smalltalk.
 There is, however, a striking thing about the C# code, qua C#, that is
 worth mentioning.
 
 It is not encapsulated.
 
 Let's start with the most obvious one.
 A bank account has a password, and you are
 supposed to provide the 

Re: [Pharo-users] Magritte seaside save

[Diego Lont]

Hi Vitor,

It has been a while that I really used Magritte, but basically the problem that 
you encounter is that the save is not called on MyObject, but on the component 
that is created from MyObject (in the method asComponent). The save method 
calls the save on the component, and in Magritte that is implemented, so 
without doing much it should perform the following code:

MAContainerComponent >> save
self validate ifFalse: [ ^ self ].
self commit; answer: self model

The validate calls the validation rules on the magritteDescription, the commit 
stores the changes the user made in the object, and answer allows the container 
to do further actions for the same event (as the button is actually created in 
the decoration, and not in the container itself).

So when you want to intercept the save method, you could use a block instead of 
a simple symbol:

MyObject new asComponent addValidatedForm : { [ :container |
| myObject |
“ do something you want to do before the save takes place “
container save.
myObject := container model.
“ when it reaches here, the save was successful and you can send a 
message to myObject, i.e. “
myObject save ] -> 'save'. #cancel -> 'cancel'}.

Another approach is to change the component that is created by overriding the 
componentClass of MyObject, and implementing the save in the new subclass you 
created.

Regards,
Diego

> On 29 Dec 2018, at 17:14, Vitor Medina Cruz  wrote:
> 
> Hello,
> 
> So:
> 
> MyObject new asComponent addValidatedForm
> 
> How do I define save callBack?
> 
> I tried:
> 
> MyObject new asComponent addValidatedForm : {#save -> 'save'. #cancel -> 
> 'cancel'}.
> 
> and defined save in both instance or class side of MyObject, but that didn't 
> work.
> 
> Regards,
> Vitor.
> 
>  
> 
>  Livre de vírus. www.avg.com 
> .
>  

Re: [Pharo-users] PetitParser: Building composed (dependent) parsers and isolating productions code

[Diego Lont]

Hi,

I have never used dependents (^ (self dependencyAt: StatementBParser)  ruleB), 
but here are my thoughts when reading this.

When parsing it makes sense to make a separation between syntax and semantics. 
Applying this functional distinction in your technical design usually makes 
sense. In practical terms making a class for the syntax (i.e. StatementASyntax) 
and one class for the semantics, subclassing the syntax (i.e. StatementASyntax 
subclass: StatementAParse).

So the question here is what class is responsible for the semantics and what 
class is responsible for the syntax. Depending on the answer on this question 
you should build your tree. Do you want your statement parsers to know the 
semantics of the statements as well, then I would suggest separate these in a 
syntax and a parser (and only having production rules in PLParser for rules 
that combine things and no production rules when the rule is merely forward 
them to your statement parser).

Or do the statement parsers merely do the syntax, and does the PLParser apply 
the semantics (maybe because the semantics is context sensitive), the you 
should not create a duplicate structure in your statement parsers, but have the 
production rules i the PLParser (or a subclass of PLParser).

As to your maintenance nightmare:
- I would add a superclass for the syntax, and not a subclass for the semantics.
- And maybe you should consider referring to the parser as a resource / factory 
method, so you only have one reference to each of your statement parsers.

PLParser>> ruleB
^ (self dependencyAt: self statementBParser) ruleB

PLParser>> statementBParser
^ StatementBParser

Regards,
Diego


> On 01 Feb 2018, at 14:42, Arturo Zambrano  wrote:
> 
> Hi All,
>  Could you please share some advice on the following situation?
>  I wrote my first Petit Parser. 
>  From the documentation I read that:
> 1) it is possible to depend on other parsers making the development more 
> modular.
>  2) The docs also suggest that, in order to separate grammars rules from 
> productions, we can make a  parser with productions  a subclass of a parser 
> which defines the grammar.
> 
> I started applying 1) so my structure is something like
> 
>   AbstractParser   " contains some common basic elements common to all 
> subclasses)
>StatementAParser
>StatementBParser   
>PLParser  "this guy uses the StatementX parsers"
> 
>  So there is a parser for different statements of the programming language.
>  The PLParser uses PetitParser dependency mechanism to rely on the 
> Statement*Parsers.For instance:
>PLParser>> ruleB
>   ^ (self dependencyAt: StatementBParser)  ruleB
> 
> 
> So far so good, the grammar is working, the parser works.
> 
> Now, I would like to write the productions, separately from the grammar part 
> (remember 2) ), so I should make subclasses adding the productions in the form
>   >>ruleA
>^super ruleA  ===> [ my production code]
> 
> The point is that PLParser explicitly depends on Statements*Parser, and the 
> name of the Statement*Parser appears here and there, so creating subclasses 
> would result in maintenance nightmare. The new layer of parsers with 
> productions will duplicate the dependencies and I foresee it will be a mess.
> 
> So now, I think that having just one big class with all the rules for the 
> grammar is better if you plan to separate productions code  isolated from the 
> grammar.
> 
> Am I right? Maybe I'm missing some point regarding writing composed parsers 
> and separating productions from grammar.
> 
> Any pointer or comment is welcome.
> 
> Arturo
> 

Re: [Pharo-users] QCMagritte on Github

[Diego Lont]

Hi,

It was somewhere on my todo list to migrate to Github, but not very high…

but I guess if someone else does this for me, I should be happy about this.

So thank you, I will look up my gut hub  account and also change the job. I 
hope to do this somewhere next week.

I know there a different configurations for different versions of pharo, so did 
you import only one version, or should there be made branches for the different 
pharo version?

Regards,
Diego

> On 27 Oct 2017, at 16:50, laurent laffont  wrote:
> 
> I've added loading instructions in README:
> 
> Metacello new
>  githubUser: 'Afibre' project: 'QCMagritte' commitish: 'master' path: 'src';
>  baseline: 'QCMagritte';
>  load.
> 
> 
> For the QCMagritte version, there's actually one branch master. If you
> need a previous version, I suppose the right way is to create a github
> branch from the desired commit in git history and adapt the
> BaselineOf...
> 
> Laurent
> 
> On Fri, Oct 27, 2017 at 2:12 PM, Hernán Morales Durand
>  wrote:
>> Nice to know Laurent,
>> 
>> Could you please comment or share how to install this version uploaded
>> to GitHub?
>> Any way to check the installed or current QCMagritte version?
>> 
>> Cheers,
>> 
>> Hernán
>> 
>> 
>> 
>> 
>> 2017-10-27 7:39 GMT-03:00 laurent laffont :
>>> Hi,
>>> 
>>> my team starts to use QCMagritte. For our needs we have imported
>>> SmalltalkHub repository to Github here:
>>> https://github.com/Afibre/QCMagritte
>>> 
>>> I don't know if you (Diego, Stephan, Tobias) plan to use Github
>>> instead of SmalltalkHub. At least Github allows branches & pull
>>> request.
>>> 
>>> Regards,
>>> 
>>> Laurent Laffont
>>> 
>> 
> 

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[Diego Lont]

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  wrote:
> 
> On 9/18/17, laurent  > 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

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[Diego Lont]

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

Re: [Pharo-users] object serialization, STON & PharoJS

[Diego Lont]

Hi,

What I remember of STON is that it simply puts out the entire tree. So it might 
include things you don’t want (like thisContext), and also does not handle 
loops well. But that is from memory, I might be wrong there.

For serialisation you could also look into the Magritte serialisation. It has 
several extenstions, among them one to output them in the JSon format. 
Disadvantage is that you have to describe your objects, but this is also helps 
you only send into the world the things you want.

Regards,
Diego

> On 16 Jul 2017, at 21:00, Siemen Baader  wrote:
> 
> Hi all, 
> 
> I’m trying to transpile the STON class to JavaScript with PharoJS to use it 
> in a client side web application. The goal is it to retrieve object(graphs) 
> from the server and deserialize them in the frontend via xhr. 
> 
> But PharoJS doesn't support thisContext, I think that's a limitation of the 
> JavaScript VM. PharoJS raises "PjJavascriptTranspilationError - thisContext 
> not supported. Found in Collection >> #toBraceStack:". I tried to add the 
>  pragma to the method in the hope that it will not be needed for 
> my uses, but no luck.
> 
> Is the use of thisContext needed in STON, can I avoid it? I had hoped to use 
> STON because it is simple and well documented and unlike JSON handles object 
> graphs and classes.
> 
> What are my options?
> 
> Alternatively, what else could I use to serialize objects? I'm already using 
> Voyage & Mongo on the backend which deal with JSON internally, and I think 
> Moose also has a serialization component. Using a JS library in the frontend 
> is also an option if there is a Pharo implementation for its format as well.
> 
> Thanks,
> Siemen

Re: [Pharo-users] Some Metacello issue

[Diego Lont]

> On 08 Jun 2017, at 09:36, Diego Lont <diego.l...@delware.nl> wrote:
> 
> Hi all,
> 
> To keep the common projects in smalltalkhub stable, we agreed that those 
> should use symbolic versions like release3 // release3.5 etc. This way we can 
> add bug fixes and avoiding loading of different versions through different 
> projects.
> 
> But I might have done something stupid to the configuration of magritte, 
> especially release3:
> 
> When I added some features to Magritte, I saw that that the stable version in 
> the configuration of Magritte3 was unstable for pharo2, 3 and 4 for quite 
> some time. Basically the tests failed, because some changes were made for 
> pharo 5 in order to let Magritte version 3.5 run. 
> 
> Since I did not have time to make a proper fix (and the error was there for 
> quite a lot of builds) for the older pharo versions and I believe the tests 
> for the stable version ought to be green, I thought the best way to fix it, 
> was to changed the #release3 magritte version back to release 3.2 for the 
> older pharo versions. Perhaps this is the cause of some of the problems. 
> Tomorrow I have time to look into this problem and make a proper fix.
> 
> Stephane already notified me this is at least a problem for Pillar …
> 
Just a small addition: I just looked at Pillar, but the build of Pillar was 
building fine until beginning of this month. My change is from the beginning of 
May …

Re: [Pharo-users] Some Metacello issue

[Diego Lont]

Hi all,

To keep the common projects in smalltalkhub stable, we agreed that those should 
use symbolic versions like release3 // release3.5 etc. This way we can add bug 
fixes and avoiding loading of different versions through different projects.

But I might have done something stupid to the configuration of magritte, 
especially release3:

When I added some features to Magritte, I saw that that the stable version in 
the configuration of Magritte3 was unstable for pharo2, 3 and 4 for quite some 
time. Basically the tests failed, because some changes were made for pharo 5 in 
order to let Magritte version 3.5 run. 

Since I did not have time to make a proper fix (and the error was there for 
quite a lot of builds) for the older pharo versions and I believe the tests for 
the stable version ought to be green, I thought the best way to fix it, was to 
changed the #release3 magritte version back to release 3.2 for the older pharo 
versions. Perhaps this is the cause of some of the problems. Tomorrow I have 
time to look into this problem and make a proper fix.

Stephane already notified me this is at least a problem for Pillar …

Regards,
Diego

> On 07 Jun 2017, at 20:01, Dale Henrichs  
> wrote:
> 
> 
> 
> On 06/07/2017 03:46 AM, Holger Freyther wrote:
>>> On 7. Jun 2017, at 14:09, Stephan Eggermont  wrote:
>>> 
>>> Never refer to fixed versions unless you know why (you need to avoid a
>>> specific bug fix).
>> When wanting to have repeatable builds (e.g. for bugfixes) and in the
>> absence of other means to lock/define versions externally, I think using
>> a fixed version is the way to go.
>> 
>> 
>>> What is most likely is that there is some overconstrained configuration.
>>> Does your ConfigurationOfVoyageMongo or one of the configurations it
>>> pulls in refer to different versions of grease or magritte? Another
>>> issue can be that there are older configurations already loaded that
>>> conflict with the newest ones. Indeed, the ConfigurationOfMongoTalk
>>> is broken, refering to a fixed and older version of Grease.
>>> ConfigurationOfVoyageMongo should probably be using #'release3' of
>>> Magritte, but that doesn't break it.
>> Right. So we have a "OsmocomUniverse" build job that pulls in all the
>> apps into a single image. This helps to make API modifications and not
>> forget any of the client code.
>> 
>> The configuration has such dependencies:
>> 
>> ConfigurationOfOsmocomUniverse
>>  -> ConfigurationOfHLR
>>  -> ConfigurationOfVoyageMongo
>>  -> Mongotalk
>>  -> Grease A
>>  -> Magritte3
>>  -> Grease B
>>  -> ConfigurationOfSMPPRouter
>>  -> ConfigurationOfVoyageMongo
>>  -> Mongotalk
>>  -> Grease A
>>  -> Magritte3
>>  -> Grease B
>> 
>> What happens is that somehow "Grease A" gets loaded, then "Grease B" and
>> when it is time for "Grease A" again.. the system kind of explodes and this
>> is for Pharo3 and Pharo6. Now the question to me is.. why is this coming
>> up right now? Did MongoTalk change or Magritte3 or something else?
>> 
>> Is there an easy way for Metacello to try a mirror instead of the original,
>> e.g. to inject an older ConfigurationOfMagritte3?
>> 
> 
> I think that the `lock` command[1] is what you are looking for ...
> 
> Dale
> 
> [1] 
> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking
>  
> 

Re: [Pharo-users] Magritte extension

[Diego Lont]

> On 22 Mar 2017, at 20:36, p...@highoctane.be wrote:
> 
> Magritte is nice but the amount of work is just too much for my taste. Simple 
> forms are better handled with somethibg like Mold.
> 
> And this especially when components interact with a ton of Js.

Then I want you to challenge you: try the QCMagritte tutorial. I took me 3 
hours, including the time to make some improvements on the tutorial, and please 
tell me if you still believe it takes a ton of time to make something nice.  

Re: [Pharo-users] Magritte extension

[Diego Lont]

> First of all I want to advertise QCMagritte: This framework is easy to use.
> It has a seaside like tutorial, that every developer should be able to
> follow without any significant problems and shows all significant features
> of both Magritte, Seaside and QCMagritte. Although it lacks documentation on
> the technical details of the framework, it has documentation included how to
> use the framework (as a developer).

Shame on me, advertising the tutorial of QCMagritte without checking it 
actually works.

I fixed the bug that prevented me from starting the first page (rendering a 
keep alive) of the tutorial this morning, and started trying it out this 
evening. Along the way I found some typo’s and things that could be explained 
better, so I made some improvements to the tutorial along the road. I also 
noticed that some topics are not covered yet in this tutorial … but since no 
one complained about the tutorial being buggy, not many people have tried the 
tutorial ?!?

Re: [Pharo-users] Magritte extension

[Diego Lont]

> On 22 Mar 2017, at 00:46, Ben Coman  wrote:
> 
> On Wed, Mar 22, 2017 at 4:35 AM, DiegoLont  wrote:
>> It has been a while that I was really involved in developing on (QC)Magritte
>> and doing stuff on the web ...
> 
> btw, what does the "QC" represent?


QC is a reference back to the company for who the software was originally 
written for: http://www.q-software-solutions.de/index.htm. The owner (Friedrich 
Dominicus) agreed that I was allowed to make the library part (QCMagritte) open 
source.

Cheers,
Diego

[Pharo-users] Improving Magritte

[Diego Lont]

Hi all,

Recently there was a question about Magritte extensions on the Pharo users 
list. It has been a while that I was really involved in developing on 
(QC)Magritte and doing stuff on the web, but on my todo list, there is feeding 
back the improvements on Magritte I have made for QCMagritte to Magritte 
itself. And while doing so, adding tests and cleaning up code where needed.

The first extension I would like to feed back into Magritte is the Builder. 

The background of the builder is the following:
- Having a custom component set, and wanting to use this custom component set 
can be very tiresome for larger applications, because you have to set a 
component class for all descriptions.
- Also it breaks the layering Magritte is trying to build in, as you need to 
"pollute" your model descriptions, with all kind of stuff, that determine how 
everything looks like. With stuff that belongs in your UI code instead of your 
model code.
I believe that the builder is a solution for this problem. The actual builder 
can be injected as an extension (for an example see the QCMagritte demo) and 
processes all descriptions. As it is a visitor, it can replace or enrich your 
descriptions with whatever you need in your UI based on the type of description.

The builder affects the way the Magritte description is created, so the package 
contains an override of magritteDescription. If I would implement this on 
Object (the most logical point), I would need to put the builder into 
Magritte-Model. Having no builders, this would of course not affect the 
returned description. Does anyone object to putting this here? And if you have 
objections, do you have a suggestion to do this elsewhere?

Cheers,
Diego