It's pretty simple ... I'll have a look at it later, shouldn't be a
problem :)
Hans
On 12/04/2011 16:18, Laurent Opprecht wrote:
Don't think moving them to content_object should be too difficult.
There is little bit of refactoring for locating, loading blocks but
not too much from what I have seen.
So far the only app I know that uses blocks is the portal.
Le 12.04.2011 16:10, Systho a écrit :
I think those blocks are so much related to the content_object that
they can't live in the repository application.
It's not if they can do half of their work without the content_object
but are fully operational with it ; they totally useless without the
content_object.
Maybe I've misunderstood your last remark but I can't find a way to
make those block cope when the content_object is not there.
I agree that making packages out of those block is a bit overkill but
does somebody know how difficult would that be to move those blocks
to the [main] content_object they are linked to and make that
content_object depdends on another if needed ?
That might be a general solution for the latest pieces of core which
still depends on content objects
If nobody knows, may someone explain me quickly the dynamics of
blocks ? are they only useful to the home application ?
Systho
Le 12/04/2011 16:00, Laurent Opprecht a écrit :
Right some blocks - possibly linker - depends on more than one
content object - streaming I believe is in the same situation.
In this case it cannot really be part of one content_object package
unless you want to make the content object package dependent of
another - which may or may not work, I would need to have a deeper
look at linker to answer this question.
The "perfect" solution would be to make those blocks packages
themselves. But I would tend to say this is too much work for the
benefits - at least for now.
On the other hand I think that the package structure should be as
orthogonal as possible. Which means adding blocks to the content
object package structure.
So I think we can leave those blocks where they are - in the
repository - and let's them cope when an object is not available.
Le 12.04.2011 15:48, Systho a écrit :
Actually some blocks depends on more than 1 content object. (Linker
depends on Link & RSS feed).
Would that work if we make Link content_object contain the block
and depends on RSSFeed content object ?
(I'm just asking because repo is not really my field)
Systho
Le 12/04/2011 15:41, Laurent Opprecht a écrit :
Make blocks a component of content object packages. So that they
can be bundled with their content object when possible.
Le 12.04.2011 15:32, Philippe Van Eerdenbrugghe a écrit :
Here I come again with my damn cyclic dependencies ^^
almost all the classes under the path
"repository\php\blocks\type\*" have dependencies to content_objects.
Does someone have an idea to break it ?
For those who don't care : cyclic dependencies are preventing a
modular application, so as long as we haven't break all those
links, we can't download a small core package and cherrypick the
additional packages. Cyclic depdencies also make the upgrade
process incredibly hard.
Systho
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
--
____________________________________
Meilleures salutations
Laurent Opprecht
chat: laurent.oppre...@gmail.com
blog: http://ciel.unige.ch/
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
--
*Hans De Bisschop*
Hoofddeskundige ICTO | Lead Developer Chamilo 2.0
Software Coordinator Chamilo Association
Erasmushogeschool Brussel
Nijverheidskaai 170 | B-1070 Brussel
T 02 559 02 54 | i 254
hans.de.bissc...@ehb.be <mailto:hans.de.bissc...@ehb.be> |
www.erasmushogeschool.be <http://www.erasmushogeschool.be/>
Kom eens langs: www.erasmushogeschool.be/infodagen
<http://www.erasmushogeschool.be/infodagen>
of lees onze elektronische nieuwsbrief: ehbrief.ehb.be
<http://ehbrief.ehb.be/>
P Before printing, think about the environment
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
