The cfproperty tags describe the data structure of the type and rule, ie what columns/types are in the db table. I understand the next release of FarCry has some automatic form generation in it, but at the moment only a basic edit form for a type is available. If you want a more sophisticated ui for type editing (eg wysiwyg html editor) you need to write it yourself - I posted another email recently that covered the basics of custom typing recently that should get you started.

The basic premise of those basics also apply to custom rules: copy a rule that does roughly what you want and edit it.

In terms of the simplification strategy: the admin changes should be quite straight forward. Something else you could do to simplify the interface would be to take away the users' permissions to view the other, now redundant, tabs.

The rules interface would be trickier, as the core setup automatically lists both core and custom types where I think you're after just the custom types. Unfortunately this involves core files and would probably be very involved. I'd suggest trying to attract the attention of Geoff or someone else from Daemon to get their input.

On 9/17/06, Jeff <[EMAIL PROTECTED]> wrote:

Thanks again Blair for the quick response.

So ... when creating a new rule, do the <cfproperty> tags defined in
the .cfc file serve to create the field options that display in the
container wizard after you select the rule and click "commit"?

Likewise, when creating a new type, do the <cfproperty> tags defined in
that .cfc file create the form fields that display in the form when you
click "add" or "edit"?

... to recap as I understand it in a nutshell, types contain all of the
core content that resides in the database populated by the forms under
the content tab in the admin, and rules dictate the options for how to
pull that data from the database and display it. Is that correct?


THE SCENARIO THAT SPARKED THIS QUESTION:

Ultimately we are trying to simplify the clients' overall experience in
the FarCry admin throughout, because much of it has proven to be
confusing for our non technical/ non web saavy clients ... sometimes
there are too many options and fields to move through.

STEP 1: Container wizard simplification
Part of this effort is to reduce (or customize) the number of options
the client sees in the container wizard; thus, our goal is to first
populate the available rule list with custom names that would be
familiar to the client; those that are directly related to the specific
content items in their site. For instance, we want to create the
following rules to display in the list: "Story", "Banner Title",
"Resources", "Project Highlights", and "More Links". Aside from the
main body content, those are the only containers the site uses, thus,
we want to eliminate "News Rule", "Random Fact Rule", "Hand Picked
Rule" and other unused rules to avoid visual confusion.

STEP 2: Content admin simplification
In the main admin, the goal to simplify is the same. We have created a
custom tab called "Modules", where we plan to cluster custom types that
will serve to populate the content for the aforementioned custom rules.
Again, for the clients' sake, we would create recognizable type names
that correspond directly to the content in their site (e.g. "Story",
"Resources", "Project Highlights", etc.).

There is name redudancy between the custom rules and types in this
situation, which is what sparked our overarching question about the
differences and functions of each.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "farcry-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/farcry-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to