Le 21/4/15 18:26, Mariano Martinez Peck a écrit :
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.
Ok I trust you. So this is good.
Now I do not know how to do crud applications with magritte.
Cheers,
On Sat, Apr 18, 2015 at 4:55 PM, stepharo <steph...@free.fr
<mailto: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
<mailto: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
