Hi Nathalie,
Thanks for pointing this out. There were apparently 2 problems:
1. Settings for optional applications (e.g. portfolio) got the wrong
context (e.g. portfolio >< application\portfolio) during
installation ... which obviously meant things went haywire
afterwards as well. This has now been fixed.
2. A few weird things were happening due to some caching (not the
optional app you introduced) causing installations of additional
objects to fail as well. This might also have had some impact on
the settings.
For existing installations / settings:
* Settings for core applications don't change, the context is still
simply the app's name (= it's namespace)
* Settings for optional applications are now prefixed with
"application\" so that the context accurately matches the
namespace. It also simplifies things like determining the
application path, rendering the form, etc.
Given that the context of the settings for optional apps has changed,
this also means the way they are invoked changes slightly. Whereas this
used to be something like e.g. PlatformSetting :: get ('first_page',
'portfolio'); it should now be PlatformSetting :: get ('first_page',
'application\portfolio'); When calling the setting from within the
application context it's probably a lot easier to simply use
__NAMESPACE__ instead.
I'll be converting all calls to those settings in the optional apps
tomorrow. (portfolio has already been "converted")
Whenever you see a "TypeName" thingy that means the name of the
application has not been translated yet into the language you're
currently using. Nothing should be missing in English, but I guess there
might be a few holes in the Dutch translation. It can cause problems,
which is why every application / co / ext repo manager / ... needs at
least that translation.
Just let me know if you run into any more problems with the settings.
Best regards,
Hans
On 09/05/2011 16:13, Nathalie Blocry wrote:
Hi Hans,
how does this impact the settings that were already present in the
applications? what needs to be changed to keep them working?
The portfolio application already had settings. I have done a complete
re-install of only the core and i notice that there is already a tab
for the portfolio-settings without the app being installed. when
clicking the tab i get an error (Fatal error: Class name must be a
valid object or a string in
/var/www/CHAMILO_BITBUCKET/DEV/common/libraries/php/application.class.php
on line/759)
/this tab seems to be for the portfolio content-object, not for the
portfolio app (when I install the app I get a new tab with only
"typename" as title but also without any settings)
/
/for the caching application I was also working with settings but they
don't appear anymore.
kind regards,
Nathalie
Op 05/06/2011 10:39 AM, Hans De Bisschop schreef:
Hi all,
This past week I've been working on a few updates and a little
cleanup of the Chamilo 2.0 portal homepage. For the most part these
changes don't break anything, but to bring everything up to the same
standards and to allow for the implementation of new functionaity due
to recent platform-wide changes, a few "tweaks" were necessary.
1. A storage unit containing all possible widgets was added, named
"home_block_registration". It contains a list of blocks
available for the homepage with their respective context (=
namespace of the package). This (in addition to previously made
architectureal changes) makes it possible to have blocks for
every single package on the system and most notably individual
content objects. This should help reduce the number of cyclic
dependencies. For those blocks like "streaming" that allow you
to use multiple types of objects I would propose individual
blocks per object type.
2. The /home_block/ storage unit no longer contains a reference to
a /context /and /component /but instead now refers to a
registration_id. The get_context method is still available and
retrieves (and caches) the registration object when needed.
/get_component/ was replaced by /get_block/ and marked as
deprecated. It will continue to work as expected for now
though. People using a PHP IDE will more then likely be
notified about the deprecation status whenever they try to call
the method.
3. Taking (2) into account, a few storage changes were required in
the /home_block/ storage unit/. context /and /block /were
removed and replaced by /registration_id/. This implies a
reinstall or manual update of this table is required. At the
same time /home_block_registration/ needs to be created and
populated.
4. ddddd
Following the move from application to context-based blocks it seemed
somewhat natural to apply the same to settings, which were also still
(more or less) limited to applications. The implications:
1. In the /admin_setting/ storage unit, /application /was replaced
by /context/. Existing content remains unchanged.
2. /get_application/ and /set_application/ have been marked
deprecated and were replaced by get_context and set_context. As
with the changes in the home_block, an intelligent PHP IDE
should alert you when you encounter calls to these deprecated
methods. Please replace them with the new methods when you
encounter such calls.
3. Practically speaking all packages can now have settings. A
visual interface to allow configuration of more then just the
application settings still needs to be implemented.
Best regards,
Hans
--
*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
_______________________________________________
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
