|
|
| Building php scripts as Plugins [message #5490] |
Tue, 06 July 2004 19:10   |
Boss Hoss
Messages: 41
Registered: July 2003
|
phpCollab friend |
|
|
| Quote: |
More projects have now stemmed from osCommerce due to the lack of module based development available within osCommerce. More often than not you find yourself modifying core osCommerce files to get your modules to work.. this is not the type of hub and spoke system you are discussing.
|
Yes that's true, but I would argue I've gotten more out of contributions for osCommerce than I have for phpcollab. Now whether the coding principles are themselves built on modular principles, probably not. They most likely represent the same hack of code we find ourselves doing in phpcollab.
What I would like is to be able to select between using TASK Module 1 and Task Module 2 through the admin for collab. So if I create a TASK Module that does time billing the way I want it, then I know I can still stay with the core of phpcollab distributions. I would of course have to make sure my TASK Module is compatible with the core files updated.
Currently a "Module" is just a hack of code for the version distributed. When you upgrade the version of phpcollab, those core files are changed.
I think we have different ways we want php collab to work for us. Instead of going our own root, maybe if contributions can be made modular and activated via an admin panel, we can stick with the core phpcollab distros.
osCommerce does IMO offer more ability to change the core function through "contributions", however when the upgrade osC I will be on my own staying with the current distro as all sites are up & running with these contributions in place.
I do maintain my own "contributed source" that I use for each new deployment. So as I find a module or put in a hack I find necessary, I do the same to my resource folder so its already in the next deployment.
My phpcollab at this point has been hacked to do what I want it to do differently that the core distro. Because I don't know how to make my contributions into a module that someone else can use, I'm on a fork I guess. I have built my own version of a billing/invoicing system that bills for stuff like web hosting and domain registration monthly as well as tallying up work tasks and creating invoices to dump in as well.
|
|
|
|
|
|
|
|
| Building php scripts as Plugins [message #5496] |
Wed, 07 July 2004 01:28 |
|
|
This maybe way off topic, but in regards to phpC thought a little history of the app would be called for...
It started from one developer, Ceam, to mimic the now defunct Macromedia SiteSpring. That being the case, I don't think there was initially any insight into modularity and integration with other applications. All in all the core code really hasn't gone any major rewrites since its inception but only little hacks and such appliaed to it. After awhile, Ceam stopped development of the application because of all the requests for "mods" and "features" that the community was wanting and he, ceam, didn't have the time to commit to developing all the requests. PhpCollab sat dead for about a year with no development what so ever being done. A group of people from the community stepped up and have been trying to revive the application with Ceam acting as a consultant. I believe that the first priority for the new dev team is to release v2.5 with all the bugs fixed. Once v2.5 is completed and released then they are wanting to do a complete re-write from the ground up. Anyone who has dabbled in the code of phpC know that its not the most friendly app to expand or develop for. As with any open soure project the number one app killer is time resources. People have other things on their plate and sometimes have a tough time trying to find time to work on the project. So, hopefully in v3 the development team, whoever it is, will be able to do a complete rework of the code and plan for future expansions, a more modular interface and the ability to interact with other 3rd party applications.
Note: I have been using/dabbling in phpC since shortly after it became public. I am not a developer of it nor a member of the development team. My comments are just my opinion of what I have read throughout the years reading the original forum on SourceForge and here. Anyway, guess I'm just rambling now so I'll shut up 
|
|
|
|
| Building php scripts as Plugins [message #5499] |
Wed, 07 July 2004 02:33 |
|
|
Through the adoption of a unified framework for the development of php applications one will be able to develop their modules/hacks into separate modular entities. This in turn allows you to leave your main application in a stock standard modular form without modifications, so that it can be upgraded in line with the development of that module, without the hassle of trying to remove any changes you might have made.
During the upgrade it might turn out that changes in the hooks of your main application model have changed slightly, and this will in turn mean you need to slightly modify your own hacks module again, but this saves you on downtime and the backward thinking involved in upgradnig modified source at its current state.
|
|
|
|
| Building php scripts as Plugins [message #5502] |
Wed, 07 July 2004 04:31 |
Boss Hoss
Messages: 41
Registered: July 2003
|
phpCollab friend |
|
|
|
I believe as someone else said, the solution starts with the proper philosophy not the actual code. The core phpCollab code would have to dictate a modular plugin design, and thus set up the parameters for adding modules to the core. But what exactly represents the "core"? This must go back to the model of a project and the process for collaborating on it.
|
|
|
|
|
|
| Building php scripts as Plugins [message #5511] |
Wed, 07 July 2004 15:09 |
Boss Hoss
Messages: 41
Registered: July 2003
|
phpCollab friend |
|
|
XOOPS is sorta like phpNuke isn't it? I don't think that's what I'm referring to at least.
In osCommerce, in the admin panel I can add a credit card processing module for Bank of America different from LinkPoint for instance. These are distinct "modules" that I can enable or disable the catalog to use. Other modules like "USPS Shipping Methods" do involve a rewrite/hack of some core files. But there are modules for FedEx separate from USPS.
So just like osC expects a "shipping" or "payment" module, I'd like to see collab expect a "task" or "billing" module that would allow me to select distinct contributions people have created to do tasks they way they envision. So if I want a time billing module MYOB style, I can install the code (nothing overwrites the core of collab) and then enable that module from admin panel. As collab core upgrades, I shouldn't be left behind as long as the module adheres to the philosophy set by collab.
|
|
|
|
| Building php scripts as Plugins [message #5513] |
Wed, 07 July 2004 15:53 |
croland
Messages: 46
Registered: October 2003
|
phpCollab friend |
|
|
From reading through the site and looking at the visual intro (http://docs.xoops.org/files/VisualIntro.pdf), what I got from it was, there is a basic operating and administrative framework.
From there there are official modules provided in the installation and optional modules that you can install.
Yeah XOOPS is a CMS, but take a quick glance at some of the modules:
http://www.xoops.org/modules/mydownloads/viewcat.php?cid=24
Some of the modules provide the functionality currently used by phpCollab, for example, calendaring, forums, user management, news, bookmarks, searching and document management.
The only modules not present (don't quote me), are project related, for example, projects, tasks, gantt charts, etc.
XoopsForge created a SourceForge clone, maybe that issue has been solved as well.
http://xoopsforge.sourceforge.net/modules/news/
XOOPS provides the same functionality you described, the ability to install and uninstall modules.
Just a thought.
|
|
|
|
| Building php scripts as Plugins [message #5582] |
Thu, 22 July 2004 07:23 |
redbox2000
Messages: 81
Registered: February 2003
Location: Connecticut
|
phpCollab lover |
|
|
It's been a long day, but I wanted to share some of my thoughts on this topic: yes, a mechanism to support modules can be built. However, given how most objects within phpC are so tightly connected and also given the nature of the product, it is really difficult to build a truly modular system. (at least w/o starting over from scratch). phpC is very unlike a CMS (e.g. Xoops, *Nuke, Mambo, etc.) where functions and features are connected, but not necessarily totally interconnected and interdependent.
The way I plan to use modules/plug-ins/add-ons is to enhance phpC core functions. For instance timesheets should -- and will -- be a core function, but the report generator that can create pretty timesheet and other reports should essentially be a plug-in. That way we can have different report generators with different complexity for different audiences. Invoicing could be another plug-in that could read the core data from the built-in timesheet, task, project, client, and vendor data objects. Anyway, that's how I'm looking at it and that's how I'm building phpCE.
By the way, I'm also allowing for "payload" data to be attached to the core project and task objects. That will allow us to track industry specific data points within the tool. For instance, if phpCE is used for publishing related projects I may want to track things like ISBN numbers, print and publishing dates. Of course, that type of data is irrelevant for software projects which instead may need track things like Alpha, Beta, and Gold dates. Payload objects will allow us to attach whatever extra data points we want to track. I'll allow users with the appropiate permissions -- PM, admins, etc. -- to create custom payload objects.
Anyway, those are my thoughts.
Greetings,
-martin.
|
|
|
|
phpCollab Community
Members
Search
Help
Login
Home
