Hello Alex!

Playing with modules before the next beta.

THE SSI is really great. Awesom. But there is one parameter that seems to be not there. If it was stored somewhere, then this SSI would be sooo Great. I mean if a field could be represented without a comm_ cap on it, do you know what I mean?

It works only if with the prefix is comm_ !!! !!! But thats troublesome. I solved it, but thinking of hundreds on the lines...

Think of comm_ = prof_ and you will see what I mean.

Or

for instance

comm_ = prof_ = gt_ (like pn_ )

So the only prefix of the fields would then be gt_ and not two different ones like how its there.

So SSI breakes......

What I mean is perhaphs

my $cols = $user_tb->cols( $CFG->{ display=>1 } );

Hi,

No, I'm afraid I don't understand. Do you mean you want to rename the columns all to gt_ rather then the mix of prof_ and comm_?

Cheers,

Alex
--
Gossamer Threads Inc.

Hi!

I really like the way how comm_ and the prof_ prefixes are designed.

What I am afraid is that in the upcoming Architecture of community, there are two different prefixes within one table. This is on one side great, as it gives a potential of handling system fields and user defined fields, on the other side it will give great difficulties to the people who may want to use and share the User_table with other applications.

I do not know how much work it may require to have a defined prefix in there like a $system_prefix (= comm_) and $user_prefix (= prof_) everywhere in the distribution! Then this may be defined like table prefix in the database.def !!! Later a user could define what should be the prefix in the users table during the installation. Or atleast I do not know how this can be implemented.

The greatest advantage of this is all the fields will be available to all the other applications other than GT applications. For e.g. I want to share the Users table which is LIVE with Postnuke:

1. This has a $prefix_users and all the fields exactly similar to Community and they all begin with pn_fieldname.
2. Users table is one of the most important one and working with it a shared table with other application is - FOR ME - most important.
3. At the same time a common authentication is equally important.

To achieve this, People may need to convert comm_ = prof_ = pn_ <% for instance %> OR all = gt_ in the users table. Making a counter argument,

If a webmaster having a database with 250.000 users in the table using postnuke or phpnuke or phpwebsite. They all have the same Architecture _more_or_less_ genrally speaking. He will have problems to use community because there are two different prefixes for GT products in the same users table. He already has a table ready but cannot use the GT applications with the postnuke/phpnuke live site without major modifications in the GT community.

I beleive GT Community should really cover many such issues also that opens a new door for all the existing users of the GT community to start using other applications on one side, and on the other side, invite other communities like phpnuke/postnuke to invite to use GT applications. Like opening doors to 30.000 users of the dynamic contents like such CMS sudenly offering all the GT products to them!

The concept of community is like a central passport and hence needs to cover such challenges too. Those were my ideas.......

I fail to beleive that this application will not be popular on the internet. I expect thousands of downloads the moment it comes in the directories everywhere. So a free product like community has a terrific potential of sale of other GT products to other CMS communities tiying other communities togather........

Ack, I missed one more point.

When there are def files that stores informations about forms, it would be nice if there is a system of storing a variable through which community understands that the fields is under no circumstances to be displayed.

hidden

invisible or no_display

If I make comm_ = prof_ then all the fields are dynamically should by the global <%Community::Web::SSI::ssi_ %> all the fields. But if there was a config variable in the def stored what fields are to be NOT shown then

by not using the SSI, I would be able to still show it dynamically.