Magritte extension
Locked
12
12
Magritte extension
 
|
Hello.
I am using Magritte to generate reports for a pharo class. I want to customize generated components in order to have a better design. My class is Match Object subclass: #Match instanceVariableNames: 'date_match hour_match status actions stadium comments teams goals1 goals2 competition' classVariableNames: '' category: MyProject-Entity' Descriptions for some variables. Stadium is also a Class. Match>>descriptionStadium <magritteDescription> ^ MASingleOptionDescription new label: 'Stadium'; priority: 305; accessor: #stadium; options: Team allStadiumsName; componentClass: TBSMagritteSelectListComponent; beRequired; yourself Match>>descriptionTeams <magritteDescription> ^ MAMultipleOptionDescription new label: 'Teams'; priority: 805; accessor: #teams; options: Team allTeamsName; componentClass: MAMultiselectListComponent; yourself The generated component in the form is not very pretty. I want to have multiple checkbox. Match>>descriptionStatus <magritteDescription> ^ MASingleOptionDescription new label: 'Status'; priority: 505; accessor: #status; options: #('Pas en cours' 'En Cours' 'Mi-temps' 'Terminé'); componentClass: TBSMagritteSelectListComponent; yourself For the report I use the class SEMatchReport TBSMagritteReport subclass: #SEMatchReport instanceVariableNames: 'report' classVariableNames: '' category: 'MyProject-Components' SEMatchReport class>>from | report matchs commandColumn | matchs := Match selectAll. report:= self rows: matchs description: (self filteredDescriptionsFrom: matchs anyOne). commandColumn := MACommandColumn new. (SEMatchReport new session isSimpleAdmin) ifTrue: [ report addColumn: (commandColumn addCommandOn: report selector: #editMatch: text: 'Modifier'; yourself; addCommandOn: report selector: #addAction: text: 'Ajouter une action'; yourself ) ] ifFalse: [ report addColumn: (commandColumn addCommandOn: report selector: #editMatch: text: 'Modifier'; yourself; addCommandOn: report selector: #deleteMatch: text: 'Supprimer'; yourself; addCommandOn: report selector: #addAction: text: 'Ajouter une action'; yourself ) ]. ^ report I want to put some bootstrapp icons near commandColumn actions. like pencil or delete on 'Supprimer'. SEMatchReport class>>filteredDescriptionsFrom: aMatch ^ aMatch magritteDescription select: [ :each | #(date_match hour_match stadium goals1 goals2 teams) includes: each accessor selector ] I notice that on the generated report on column stadium we have aStadium. We don't have the value (the name). I don't know how to mention it in the filtered descriptions. Change the color of lines in the report, etc. All that things. Sorry for the bad english. Thanks. Asbath |
|
|
Hi, Before a longer answer, what is TBSMagritteReport ? Is it yours or is it some magritte extension for Bootstrap? Thanks, On Fri, Mar 17, 2017 at 3:54 AM, Asbath Sama biyalou <[hidden email]> wrote: Hello. |
Re: Magritte extension
|
|
On 17/03/2017 12:23, Mariano Martinez
Peck wrote:
It is a magritte extension for Bootstrap. Or which one are you using? Asbath |
|
|
In reply to this post by Mariano Martinez Peck
2017-03-17 8:23 GMT-03:00 Mariano Martinez Peck <[hidden email]>:
> Hi, > > Before a longer answer, what is TBSMagritteReport ? Is it yours or is it > some magritte extension for Bootstrap? It is a Twitter Boostrap styled (with TBS classes) Magritte Report. Regards, Esteban A. Maringolo |
|
|
In reply to this post by Pharo Smalltalk Users mailing list
Hi asbath
can you attach your code? So that we can load it in a magritified image? Stef On Fri, 17 Mar 2017 07:54:37 +0100, Asbath Sama biyalou via Pharo-users <[hidden email]> wrote: > Hello. > > I am using Magritte to generate reports for a pharo class. I want to > customize generated components in order to have a better design. > > My class is Match > > Object subclass: #Match > instanceVariableNames: 'date_match hour_match status actions stadium > comments teams goals1 goals2 competition' > classVariableNames: '' > category: MyProject-Entity' > > > Descriptions for some variables. > > Stadium is also a Class. > > Match>>descriptionStadium > <magritteDescription> > ^ MASingleOptionDescription new > label: 'Stadium'; > priority: 305; > accessor: #stadium; > options: Team allStadiumsName; > componentClass: TBSMagritteSelectListComponent; > beRequired; > yourself > > > Match>>descriptionTeams > <magritteDescription> > ^ MAMultipleOptionDescription new > label: 'Teams'; > priority: 805; > accessor: #teams; > options: Team allTeamsName; > componentClass: MAMultiselectListComponent; > yourself > > > The generated component in the form is not very pretty. I want to have > multiple checkbox. > > > Match>>descriptionStatus > <magritteDescription> > ^ MASingleOptionDescription new > label: 'Status'; > priority: 505; > accessor: #status; > options: #('Pas en cours' 'En Cours' 'Mi-temps' 'Terminé'); > componentClass: TBSMagritteSelectListComponent; > yourself > > > For the report I use the class SEMatchReport > > TBSMagritteReport subclass: #SEMatchReport > instanceVariableNames: 'report' > classVariableNames: '' > category: 'MyProject-Components' > > > SEMatchReport class>>from > | report matchs commandColumn | > matchs := Match selectAll. > report:= self rows: matchs description: (self > filteredDescriptionsFrom: matchs anyOne). > commandColumn := MACommandColumn new. > (SEMatchReport new session isSimpleAdmin) > ifTrue: [ > report addColumn: (commandColumn > addCommandOn: report selector: #editMatch: text: 'Modifier'; > yourself; > addCommandOn: report selector: #addAction: text: 'Ajouter > une action'; yourself ) ] > ifFalse: [ > report addColumn: (commandColumn > addCommandOn: report selector: #editMatch: text: 'Modifier'; > yourself; > addCommandOn: report selector: #deleteMatch: text: > 'Supprimer'; yourself; > addCommandOn: report selector: #addAction: text: 'Ajouter > une action'; yourself ) ]. > ^ report > > I want to put some bootstrapp icons near commandColumn actions. like > pencil or delete on 'Supprimer'. > > > SEMatchReport class>>filteredDescriptionsFrom: aMatch > ^ aMatch magritteDescription select: [ :each | #(date_match > hour_match stadium goals1 goals2 teams) > includes: each accessor selector ] > > I notice that on the generated report on column stadium we have > aStadium. We don't have the value (the name). I don't know how to > mention it in the filtered descriptions. > > Change the color of lines in the report, etc. All that things. > > Sorry for the bad english. > > Thanks. > > Asbath > > -- Using Opera's mail client: http://www.opera.com/mail/ |
|
|
In reply to this post by Pharo Smalltalk Users mailing list
Hi Asbath,
Some answers below. But a general comment is that the typical case to customize magritte is by subclassing and then somehow use your own subclasses instead of magritte ones. On Fri, Mar 17, 2017 at 3:54 AM, Asbath Sama biyalou <[hidden email]> wrote: Hello. In my case, I have customized ALL the components I use for Magritte. That is, I have my own Fa version (Fa is my package prefix). So I have FaMAMultiselectListComponent subclass of MAMultiselectListComponent. I have FaTBSMagritteSelectListComponent, subclass of TBSMagritteSelectListComponent , etc... so basically, you subclass and override the parent methods you want. Most common methods you need to override are renderEditorOn: html or renderViewerOn: html etc...but that depends on WHAT you want to change and in WHICH component. Note they are all subclasses of MADescriptionComponent. You can also set your own properties in the magritte so that you can read them at your component level. For example, above I could say: Match>>descriptionTeams <magritteDescription> ^ MAMultipleOptionDescription new label: 'Teams'; priority: 805; accessor: #teams; options: Team allTeamsName; propertyAt: 'showInMultipleCheckboxs' put: true; componentClass: FaMAMultiselectListComponent; yourself Then in the rendering code of your subclass FaMAMultiselectListComponent you can do: (self magritteDescription propertyAt: 'showInMultipleCheckboxs') ifTrue: [ self renderAsMultiCheckboxsOn: html... ] ifFalse: [ ... ] Of course, you can even define the accessors for #showInMultipleCheckboxs as extension methods in MADescription To avoid having to define FaMAMultiselectListComponent for each MAMultipleOptionDescription .. well, there are many ways. But I guess that is for a later topic. Ask me if you want this.
To do this, again, subclass MACommandColumn, override renderCellContent:on: and use your particular subclass.
That's weird. I don't know.
In this case I don't use the magritte row/even css classes. In my case, I have a subclass of MAReport (I guess you can subclass from the Bootstrap one) and changed the table rendering to use: table beHover; beBordered; beCondensed; beStriped; etc... so I let colors to Bootstrap / CSS. Cheers, Sorry for the bad english. |
|
|
On 18/03/17 18:40, Mariano Martinez Peck wrote:
> Some answers below. But a general comment is that the typical case to > customize magritte is by subclassing and then somehow use your own > subclasses instead of magritte ones. Well, there are lots of ways to customize magritte. So many actually, that it is definitely non-trivial to decide where to extend what. For your first experiments with extending magritte, just subclassing is definitely the way to go. You need a way to understand how the different parts in magritte interact, and the easiest way is to change something and see what it does. In QCMagritte we've gone much farther. Some problems (access control, translation) are much easier solved by modifying the visitor used to render the html. By chaining multiple visitors, it becomes easy to translate all labels and help-texts without polluting the magritte descriptions or the domain objects. The same goes for access control. Stephan |
|
|
I never managed to take a look at QCMagritte but it sounds as an extension. Why was it never integrated?
Norbert Von meinem iPad gesendet > Am 19.03.2017 um 10:06 schrieb Stephan Eggermont <[hidden email]>: > >> On 18/03/17 18:40, Mariano Martinez Peck wrote: >> Some answers below. But a general comment is that the typical case to >> customize magritte is by subclassing and then somehow use your own >> subclasses instead of magritte ones. > > Well, there are lots of ways to customize magritte. So many actually, that it is definitely non-trivial to decide where to extend what. For your first experiments with extending magritte, just subclassing is definitely the way to go. You need a way to understand how the different parts in magritte interact, and the easiest way is to change something and see what it does. > > In QCMagritte we've gone much farther. Some problems (access control, translation) are much easier solved by modifying the visitor used to render the html. By chaining multiple visitors, it becomes easy to translate all labels and help-texts without polluting the magritte descriptions or the domain objects. The same goes for access control. > > Stephan > > > > |
Re: Magritte extension
|
|
In reply to this post by Mariano Martinez Peck
Thanks Mariano for the ideas. I will put them into practice. Then All I have to do is to extends magritte classes to customize them. On 18/03/2017 18:40, Mariano Martinez
Peck wrote:
Cheers, Asbath |
|
|
In reply to this post by Mariano Martinez Peck
Hi,
We also made several sub-classes of Magritte classes and / or components. This causes a lot of problems because when we upgraded Magritte it was difficult. It also shows that Magritte (the core classes) cannot change much because the impact will be high for most users of Magritte. This makes us think that Magritte is not easy to use or customise. And it also appears as if all the custom changes are not being generalised into the framework. Perhaps us users of Magritte should stand back and discuss our changes and issues more so that we can improve it? I suppose we need some magritte champion(s) to take it somewhere. To get more flexibility with Magritte styling we are using CSS and classes more in stead of rendering in a different way. Often one can get away with adding a CSS class and changing the style sheet. This is a bit fluffy, but it there's a lot of stuff to talk about here. In principle, are you sharing my frustration with Magritte? Cheers Otto On Sat, Mar 18, 2017 at 7:40 PM, Mariano Martinez Peck <[hidden email]> wrote: > Hi Asbath, > > Some answers below. But a general comment is that the typical case to > customize magritte is by subclassing and then somehow use your own > subclasses instead of magritte ones. > > On Fri, Mar 17, 2017 at 3:54 AM, Asbath Sama biyalou > <[hidden email]> wrote: >> >> Hello. >> >> I am using Magritte to generate reports for a pharo class. I want to >> customize generated components in order to have a better design. >> >> My class is Match >> >> Object subclass: #Match >> instanceVariableNames: 'date_match hour_match status actions stadium >> comments teams goals1 goals2 competition' >> classVariableNames: '' >> category: MyProject-Entity' >> >> >> Descriptions for some variables. >> >> Stadium is also a Class. >> >> Match>>descriptionStadium >> <magritteDescription> >> ^ MASingleOptionDescription new >> label: 'Stadium'; >> priority: 305; >> accessor: #stadium; >> options: Team allStadiumsName; >> componentClass: TBSMagritteSelectListComponent; >> beRequired; >> yourself >> >> >> Match>>descriptionTeams >> <magritteDescription> >> ^ MAMultipleOptionDescription new >> label: 'Teams'; >> priority: 805; >> accessor: #teams; >> options: Team allTeamsName; >> componentClass: MAMultiselectListComponent; >> yourself >> >> >> The generated component in the form is not very pretty. I want to have >> multiple checkbox. > > > > In my case, I have customized ALL the components I use for Magritte. That > is, I have my own Fa version (Fa is my package prefix). So I have > FaMAMultiselectListComponent subclass of MAMultiselectListComponent. I have > FaTBSMagritteSelectListComponent, subclass of TBSMagritteSelectListComponent > , etc... so basically, you subclass and override the parent methods you > want. Most common methods you need to override are renderEditorOn: html or > renderViewerOn: html etc...but that depends on WHAT you want to change and > in WHICH component. Note they are all subclasses of MADescriptionComponent. > > You can also set your own properties in the magritte so that you can read > them at your component level. For example, above I could say: > > Match>>descriptionTeams > <magritteDescription> > ^ MAMultipleOptionDescription new > label: 'Teams'; > priority: 805; > accessor: #teams; > options: Team allTeamsName; > propertyAt: 'showInMultipleCheckboxs' put: true; > componentClass: FaMAMultiselectListComponent; > yourself > > > Then in the rendering code of your subclass FaMAMultiselectListComponent you > can do: > > (self magritteDescription propertyAt: 'showInMultipleCheckboxs') ifTrue: [ > self renderAsMultiCheckboxsOn: html... > ] ifFalse: [ > ... > ] > > Of course, you can even define the accessors for #showInMultipleCheckboxs as > extension methods in MADescription > > > To avoid having to define FaMAMultiselectListComponent for each > MAMultipleOptionDescription .. well, there are many ways. But I guess that > is for a later topic. Ask me if you want this. > > >> >> >> Match>>descriptionStatus >> <magritteDescription> >> ^ MASingleOptionDescription new >> label: 'Status'; >> priority: 505; >> accessor: #status; >> options: #('Pas en cours' 'En Cours' 'Mi-temps' 'Terminé'); >> componentClass: TBSMagritteSelectListComponent; >> yourself >> >> >> For the report I use the class SEMatchReport >> >> TBSMagritteReport subclass: #SEMatchReport >> instanceVariableNames: 'report' >> classVariableNames: '' >> category: 'MyProject-Components' >> >> >> SEMatchReport class>>from >> | report matchs commandColumn | >> matchs := Match selectAll. >> report:= self rows: matchs description: (self >> filteredDescriptionsFrom: matchs anyOne). >> >> commandColumn := MACommandColumn new. >> >> (SEMatchReport new session isSimpleAdmin) >> ifTrue: [ >> report addColumn: (commandColumn >> addCommandOn: report selector: #editMatch: text: 'Modifier'; >> yourself; >> addCommandOn: report selector: #addAction: text: 'Ajouter >> une action'; yourself ) ] >> ifFalse: [ >> report addColumn: (commandColumn >> addCommandOn: report selector: #editMatch: text: 'Modifier'; >> yourself; >> addCommandOn: report selector: #deleteMatch: text: >> 'Supprimer'; yourself; >> addCommandOn: report selector: #addAction: text: 'Ajouter >> une action'; yourself ) ]. >> >> ^ report >> >> I want to put some bootstrapp icons near commandColumn actions. like >> pencil or delete on 'Supprimer'. >> > > > To do this, again, subclass MACommandColumn, override renderCellContent:on: > and use your particular subclass. > > >> >> >> SEMatchReport class>>filteredDescriptionsFrom: aMatch >> ^ aMatch magritteDescription select: [ :each | #(date_match >> hour_match stadium goals1 goals2 teams) >> includes: each accessor selector ] >> >> I notice that on the generated report on column stadium we have >> aStadium. We don't have the value (the name). I don't know how to >> mention it in the filtered descriptions. > > > > That's weird. I don't know. > >> >> >> Change the color of lines in the report, etc. All that things. >> > > In this case I don't use the magritte row/even css classes. > > In my case, I have a subclass of MAReport (I guess you can subclass from the > Bootstrap one) and changed the table rendering to use: > > table > beHover; > beBordered; > beCondensed; > beStriped; > > etc... so I let colors to Bootstrap / CSS. > > > Cheers, > > >> >> Sorry for the bad english. >> >> Thanks. >> >> Asbath >> > > > > -- > Mariano > http://marianopeck.wordpress.com |
|
|
2017-03-20 7:18 GMT-03:00 Otto Behrens <[hidden email]>:
> Hi, > > We also made several sub-classes of Magritte classes and / or > components. This causes a lot of problems because when we upgraded > Magritte it was difficult. It also shows that Magritte (the core > classes) cannot change much because the impact will be high for most > users of Magritte. This makes us think that Magritte is not easy to > use or customise. And it also appears as if all the custom changes are > not being generalised into the framework. Perhaps us users of Magritte > should stand back and discuss our changes and issues more so that we > can improve it? I suppose we need some magritte champion(s) to take it > somewhere. > > To get more flexibility with Magritte styling we are using CSS and > classes more in stead of rendering in a different way. Often one can > get away with adding a CSS class and changing the style sheet. > > This is a bit fluffy, but it there's a lot of stuff to talk about > here. In principle, are you sharing my frustration with Magritte? I'm not frustrated, but I share the feeling that we're missing valuable contributions from other users. The thing with Magritte is that everything is done by subclassing, the metamodel part (MADescription subclasses) is pretty composable, but the seaside components are bound to whatever CSS framework is chosen, there isn't much to do there other than subclassing. This has several drawbacks to integrate code from different teams/projects, because you end up having to use a whole set of classes from the "foreign" library (e.g. QCMagritte) rather than just a few components. One thing that I disliked is the fact that from Magritte 2 to 3 the descriptions moved from the class side to the instance side, to allow dynamic containers based on instance state/behavior, this is really powerful, but I'd preferred a two step lookup to build the instances, it is... look at the instance side first, and then class side, this way you can manipulate description without having to instantiate a sample instance. This is mandatory if you're building an UI like a reporting, querying tool where do not know in advance which instances are going to be returned. However I think this is a discussion for the Magritte, or Seaside, mailing list. Regards, -- Esteban |
|
|
In reply to this post by NorbertHartl
On 19/03/17 14:14, Norbert Hartl wrote:
> I never managed to take a look at QCMagritte but it sounds as an extension. Why was it never integrated? It is rather a monolitical extension. And it was mostly in heavy development. We never stopped to make a real release. Somehow the tutorial code and the demo's were not enough to get traction in the community. Probably too much change at a time. I think the design is sound but we never got into discussions/feedback about that. We ran into the instance side problem too, and solved that with prototypes. You need them anyway to get better memento's. Stephan |
|
|
Hi,
> Am 21.03.2017 um 08:04 schrieb Stephan Eggermont <[hidden email]>: > > On 19/03/17 14:14, Norbert Hartl wrote: >> I never managed to take a look at QCMagritte but it sounds as an extension. Why was it never integrated? > > It is rather a monolitical extension. And it was mostly in heavy development. We never stopped to make a real release. Somehow the tutorial code and the demo's were not enough to get traction in the community. Probably too much change at a time. I think the design is sound but we never got into discussions/feedback about that. > do you have any documentation that summarizes the changes you did. With all the new mails about magritte and problems it might be time to form a new group caring about a new implementation of a meta-object layer. I think now that we have slots the implementation can be made much more powerful than magritte is today. > We ran into the instance side problem too, and solved that with > prototypes. You need them anyway to get better memento's. > Same here. There are times where it seems cumbersome to use the instance side descriptions. But the benefits outweigh that problem by far (for me at least). But I do like the idea that instance _and_ class side descriptions are taken into account. Feels right at first. Norbert |
|
|
> do you have any documentation that summarizes the changes you did. With all the new mails about magritte and problems it might be time to form a new group caring about a new implementation of a meta-object layer. I think now that we have slots the implementation can be made much more powerful than magritte is today.
+1 >> We ran into the instance side problem too, and solved that with >> prototypes. You need them anyway to get better memento's. >> > Same here. There are times where it seems cumbersome to use the instance side descriptions. But the benefits outweigh that problem by far (for me at least). But I do like the idea that instance _and_ class side descriptions are taken into account. Feels right at first. We needed to retain the class side descriptions and hacked the new magritte to still do the old class side thing using the <magritteDescription> pragma. (ulgy) This is because we use MAReport with MADescribedColumn a lot. This often have to be on the class side because the column applies to all the rows in the report. How do you guys to table-like lists of things? We have an extension to use the descriptions to edit the cells in the table as well, for the case where you need to edit various columns in a list. The standard MAReport is read only, as I understand it. Do you have the requirement to edit tables? And how do you do that? |
|
|
2017-03-21 7:41 GMT-03:00 Otto Behrens <[hidden email]>:
>> do you have any documentation that summarizes the changes you did. With all the new mails about magritte and problems it might be time to form a new group caring about a new implementation of a meta-object layer. I think now that we have slots the implementation can be made much more powerful than magritte is today. > > +1 >>> We ran into the instance side problem too, and solved that with >>> prototypes. You need them anyway to get better memento's. >>> >> Same here. There are times where it seems cumbersome to use the instance side descriptions. But the benefits outweigh that problem by far (for me at least). But I do like the idea that instance _and_ class side descriptions are taken into account. Feels right at first. > > We needed to retain the class side descriptions and hacked the new > magritte to still do the old class side thing using the > <magritteDescription> pragma. (ulgy) > > This is because we use MAReport with MADescribedColumn a lot. This > often have to be on the class side because the column applies to all > the rows in the report. How do you guys to table-like lists of things? > > We have an extension to use the descriptions to edit the cells in the > table as well, for the case where you need to edit various columns in > a list. The standard MAReport is read only, as I understand it. Do you > have the requirement to edit tables? And how do you do that? I don't use it in MAReports, but I define queries based on the descriptions for instances yet unknown, so the use case is similar. Currently what I did is an approach similar to how Dolphin Smalltalk handles its "Aspects", e.g. Model>>mementoClass ^self class mementoClassOfInstances Model class>>mementoClassOfInstances ^MACheckedMemento And this can be done for almost everything, incluiding building the description container, ask the instance first, and then the class. Also, I like the pragmas, but only for "tagging" the description methods, I prefer lookup and builds based on simple message sends. Regards, Esteban A. Maringolo |
|
|
In reply to this post by Pharo Smalltalk Users mailing list
Hi all,
It has been a while that I was really involved in developing on (QC)Magritte and doing stuff on the web ... I am all in favour of forming a group of active people to do some improvements on Magritte. I wrote on my todo list that I should feed back some of the improvements made in QCMagritte back to Magritte, but feeling a lack of interest from the community it dropped of my list. Maybe now is a good time to find some room in my schedule for doing so. 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). Secondly. I agree that the most easy customisation of Magritte is using custom components. The Magritte components provided are quite basic. That is why in QCMagritte there is a number of components included that support AJAX functionality. It also contains a component that allows inline editing in a report. The idea about Magritte is also that the descriptions do not require a certain set of components. I.e. there was also an attempt on creating a Morph set of components ... that is a bit incomplete. Third. Feeding the improvements I have made in QC Magritte back into Magritte should probably be discussed this on the Magritte mailinglist. So I will do this in a separate post, mailing to bost lists. Cheers, Diego |
|
|
On Wed, Mar 22, 2017 at 4:35 AM, DiegoLont <[hidden email]> 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? cheers -ben |
|
|
> On 22 Mar 2017, at 00:46, Ben Coman <[hidden email]> wrote: > > On Wed, Mar 22, 2017 at 4:35 AM, DiegoLont <[hidden email]> 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 |
|
|
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. Phil Le 22 mars 2017 19:53, "Diego Lont" <[hidden email]> a écrit :
|
|
|
In reply to this post by DiegoLont
> 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 ?!? |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |