Hi,
We've been using Margritte-Seaside for about 6 years now. And we've been hacking around and monkey patching magritte to force it into submission. I'm trying to improve on this approach, as you may agree. I would in general like to understand Margritte better, but perhaps start with: how do you suggest we customise the rendering of a described component? We know of a few hooks, but is there some documentation I can read on this subject? I know my question is vague, but I have so many, and would like to just start somewhere and then dive into more specifics. Please let me know if I should dive into specifics. Further, is this the best mailing list to post on? Thanks Otto _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
On 10-06-15 16:34, Otto Behrens wrote: > I'm trying to improve on this approach, as you may agree. I would in > general like to understand Margritte better, but perhaps start with: > how do you suggest we customise the rendering of a described > component? We know of a few hooks, but is there some documentation I > can read on this subject? The most important change we made in QCMagritte is the chaining of the visitors used to do the rendering. That made it possible to work with a separate visitor for a.o. translations, rights and roles, and bootstrap instead of plain seaside. In 2013 and 2014 we presented QCMagritte at Esug, so there are videos available on youtube. > Further, is this the best mailing list to post on? Yep. Stephan _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
I had a peek at QCMagritte and need to spend more time there. If we've
got an extensive app built with Magritte, is it a major issue to use QCMagritte? On Fri, Jun 12, 2015 at 9:24 AM, stephan <[hidden email]> wrote: > > > On 10-06-15 16:34, Otto Behrens wrote: >> >> I'm trying to improve on this approach, as you may agree. I would in >> general like to understand Margritte better, but perhaps start with: >> how do you suggest we customise the rendering of a described >> component? We know of a few hooks, but is there some documentation I >> can read on this subject? > > > The most important change we made in QCMagritte is the chaining of > the visitors used to do the rendering. That made it possible to work with > a separate visitor for a.o. translations, rights and roles, and bootstrap > instead of plain seaside. > > In 2013 and 2014 we presented QCMagritte at Esug, so there are videos > available on youtube. > > >> Further, is this the best mailing list to post on? > > > Yep. > > Stephan > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
On 12-06-15 10:29, Otto Behrens wrote: > I had a peek at QCMagritte and need to spend more time there. If we've > got an extensive app built with Magritte, is it a major issue to use > QCMagritte? The chaining of visitors is what allowed us to remove most duplication, and avoid a lot of special components. The navigation support through QCParentObject is also going to lead to some code changes. Stephan _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Administrator
|
In reply to this post by Stephan Eggermont-3
I've always wondered why you forked rather than fixing Magritte. I've made a lot of enhancements and non-backward compatible changes to Magritte with zero pushback. It's a shame to maintain two projects...
Cheers,
Sean |
> Stephan Eggermont wrote
>> The most important change we made in QCMagritte is the chaining of >> the visitors used to do the rendering > > I've always wondered why you forked rather than fixing Magritte. I've made a > lot of enhancements and non-backward compatible changes to Magritte with > zero pushback. It's a shame to maintain two projects... +1 same problem here _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by Sean P. DeNigris
It is not a fork, it is just add-ons and a certain way of using Magritte.
Stephan On 13-06-15 03:16, Sean P. DeNigris wrote: > Stephan Eggermont wrote >> The most important change we made in QCMagritte is the chaining of >> the visitors used to do the rendering > I've always wondered why you forked rather than fixing Magritte. I've made a > lot of enhancements and non-backward compatible changes to Magritte with > zero pushback. It's a shame to maintain two projects... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/customising-rendering-of-components-tp4831424p4832181.html > Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com. > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Administrator
|
Ah! That, I was not expecting. Now I will have to take a much closer look at QC :)
Cheers,
Sean |
On 13-06-15 12:17, Sean P. DeNigris wrote: > Stephan Eggermont wrote >> It is not a fork, it is just add-ons and a certain way of using Magritte. > Ah! That, I was not expecting. Now I will have to take a much closer look at > QC :) Which doesn't mean that it shouldn't be better integrated and probably replace some default behavior... Stephan _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Free forum by Nabble | Edit this page |