El Friday 14 November 2008 16:49:28 Brett R. Edgar escribió: > Perhaps we need to re-think this whole plugin system. I've so far > discovered the following two issues: > > 1) The ApplicationLogs filters logs from uninstalled plugins by getting the > object manager class name as a lower-case string and then checking to see > if a plugin by that name exists. > > I discovered this while trying to create a "Time" plugin incorporating all > the TimeTracker code. However, the object manager for application logs from > that plugin is called ProjectTimes. Now, I've worked around this relatively > easily by adding a column to the plugins table called 'log_providers' and > asking the plugin's init.php script for a list of those. > > 2) Public files and images. This is a major deficiency in the current > plugin architecture. The plugin can't provide any static content without > writing outside the /application/plugins/ directory structure. Allowing a > plugin to do so would violate the principle of isolating plugins from each > other. It would also make plugins harder to add and remove completely. > > I discovered this because the "Wiki" plugin creates application logs, which > when displayed on the dashboard tries to show an image in the left-hand > column of the log entry. The wiki plugin can't distribute an image for > every possible theme, though, and it would have to install that image > outside of its plugin directory. Both of these situations are unacceptable. > I can't solve this problem because the sequence of functions called > (image_url() -> get_image_url() -> get_public_url()) makes it hard to check > if a file exists and provide another default location if it doesn't. And > that is not even mentioning the configuration headache installing PP would > incur in getting Apache to serve public files out of another directory in > addition to /public/.
What do you think about copying plugin files to /public/plugins/<plugin_name>? It's easy to remove public files from a plugin, and plugins are isolated from each other. Maybe it's necessary get_public_url (or get_image_url, I'm not sure) checks all /public/plugins directories if the file doesn't exist in /public. Although if plugin can say image is in plugins/<plugin_name>, it might fix this problem > > So does anyone have any thoughts on how to solve these two issues? Can > anyone think of any further issues like this that we may encounter? I'm > sure as we create more plugins we are going to run into more issues like > this. We may not be able to anticipate all of them until we encounter them, > which means we need a lot more people contributing test plugins. > > My initial fear is that adding proper plugin support to the system is going > to require so many changes that it would be better to completely > re-architect ProjectPier. Plugins need to be pushed into the Env classes, > not some hack-job add-on. A plugin system's needs are low-level enough > that they should be part of the *core* application. The same goes for > extensible permissions. > > Plugins are making me very sad today. > > -- > =================== > Brett Edgar > True Digital Security, Inc./DESA Research, LLC. > [EMAIL PROTECTED] > 866.430.2595 x 103 > www.truedigitalsecurity.com -- Sergio Cambra .:: entreCables - Symbol Servicios Informáticos S.L. ::. Nicolás Guillén 6, locales 2 y 3. 50.018 Zaragoza T) 902 021 404 F) 976 52 98 07 E) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Projectpier-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/projectpier-development
