Hi Stef, Similar to what Yanni said, 99% of our extensions are to Magritte-Seaside, not to magritte core itself. I honestly see Magritte as a very small and super extensible framework from which you can build your own on top of it. Like QCMagritte. Or likely what Yanni did, or likely what we did. That is...a set of subclasses/extensions to Magritte Seaside. This doesn't mean we shouldn't make this open-source, but I am just saying all our extensions should not be Magritte core code but kind of a framework build on top of Magritte core.
Just to give you an idea of the extensibility of Magritte... is that with all our framework build on top of Magritte, we had NO OVERRIDE and our classes/extensions load cleanly after loading Magritte. Cheers, On Sat, Apr 18, 2015 at 4:55 PM, stepharo <steph...@free.fr> wrote: > And BTW I would really like to see how we can do crude with > magritte-described objects. > > > Le 18/4/15 21:37, stepharo a écrit : > > >> >> Le 18/4/15 20:04, Yanni Chiu a écrit : >> >>> On Apr 18, 2015, at 2:18 AM, stepharo <steph...@free.fr> wrote: >>> >>> I found strange that not a single little improvements of Magritte was >>>> necessary for the Qude project. >>>> >>> It’s not strange to me, because when working with Magritte 2, it seemed >>> that almost everything I wanted to do had a hook method to override, or an >>> obvious place to subclass or extend. So much so, that when I could not find >>> the extension point, I thought it was my fault. What was missing was >>> instance-based descriptions, which was added by the community in Magritte 3. >>> >> >> :) >> >> >>> Given how well-factored Magritte 2 was, my deduction was that a lot of >>> effort had already been done to extract out an open-source artefact, from >>> whatever system drove it’s development. So, no surprise that few >>> improvements to the core Magritte were needed. >>> >> >> Ok so we have perfect software. Good to know. >> >>> Now if heavy users of open-source libraries do not enhance these >>>> open-source libraries and keep their extensions >>>> under close source then the open-source libraries will never make >>>> progress and I will immensely sad. >>>> >>> Given that Magritte is already well-factored for extensions, what tends >>> to be written is exactly the custom code which you would not be releasing >>> to open-source. >>> >> >> but you see I did not use magritte since long time. It would be great to >> have example of custom-code. >> For example are relationships any useful. >> >>> >>> However, there might be a case for add-ons, such as Twitter Bootstrap >>> support. As mentioned in another post, changing the Magritte API/interfaces >>> at this point is tricky, because it would affect current users - that’s the >>> conundrum: success and wider adoption will constrain the evolution. >>> >> We have versions to help there. >> >> The addition of instance-based descriptions was worth the (minor) pain >>> of the transition, but what level of pain would be tolerable to add >>> Bootstrap support, especially if you’re not using Bootstrap. >>> >> But we are talking about SeasideMagritte here? >> I do not know because I do not have experience. >> I was talking about magritte. >> >> >> >> >> > > -- Mariano http://marianopeck.wordpress.com
