I have done a significant amount of work (not in production yet) towards such a thing. I have at least two versions of it that I am not completely happy with yet.
Concept One: Extend the FarCry container system to allow containers within containers. Then label all your containers with a key that includes the users login information. Then simply use the existing management tools. Concept Two: Model the system on FarCry containers but create separate Container and Rule objects that are designed specifically for "portal" style work and develop appropriate admin tools that more suit the "Yahoo" style of editing. Concept Three: Model the system as a completely separate sub-system that just "works" with FarCry. I choose to NOT go with Concept One as I felt the container management system would not be user-friendly enough for the people that would be playing with it. In addition, my containers would have to do things that would not easily fit into the existing container model. AND - I didn't really want "ADMIN" types coming to "user" based containers (remember they would be logged in as themselves) and not being able to "see" what a particular user was seeing (meaning the new system would have to still be capable of allowing an ADMIN person full control so they can help users). Also, I did not want to clutter the general RULE data space with "user defined" rules. I experimented with Concept Two. This involved a "manager" class that would retrieve preferences for a user. These "preferences" were stored in a FarCry object similar to a RULE that had additional information to indicate which column the information belonged in FOR THAT USER. NOTE: this would potentially make this "RULE" table grow VERY big if you have a lot of users. The "manager" class would then become the controller that you interrogate when you what to display the content for each of the columns (executing the display methods of the rules at the time the content was requested). This works. However, there were a number of things (including performance) that I was not happy with. So I then experimented with the third concept. As far as "performance" goes - this one was better. In this concept, it was decided that the "dynamism" of variable display methods, etc. was not necessary. Of course, the user could still provide parameters (like STATE for example) that could tailor the output, but the "container" became a "panel" and the "rule" became "content". A more "traditional" object oriented approach was taken. The "content" object simply had a "display" method that I would override in a derived class and this "widget" would just know what do with itself. This approach also turned out to be not only the quickest of the ones I had tried - but programmatically was easier to understand - but still flexible. Unfortunately, at that point in time the team was diverted off onto a very large project and the work has lain dormant since - so is not finished. It was my full intention to release the final result into the FarCry public domain. I guess I will still do that if it ever gets finished. Regards, Gary [PS - since then, the concepts have been used in the recent large project - but with no ability for a user to tailor what they see or the order in which it appears. Sorry, can't show a demo - internal application, confidential data, etc.] On Wed, 15 Dec 2004 01:46:45 +1100, Tom Barr <[EMAIL PROTECTED]> wrote: > Is there a common way to accomplish these things within FarCry? My first > thoughts are to make my templates more dynamic and store user preferences > in XML or in an extension of a type. --- You are currently subscribed to farcry-dev as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
