I want to start a thread on the "changes" in logic between the 1.x versions and the new version (whatever it's called <G>)

Firstly, I see a lot of new paramters, such as 'gb' added to the new/cool pages, which eliminates one of my pet peve hacks :)

Also, I see that the user scripts in the admin area are really 'shells' that simply are ordering the calls to various modules and passing them parameters. I've also noticed the calls to the fuctions are hard-coded with absolute paths, which means that relocation of the modules and the functions within the modules is not going to be easily effected. ie: We are locked into this layout.

That has good and bad features -- good if it works, it standardizes design. Bad if it's found it doesn't, it means major blocks of code change, and minor changes ripple throughout the various plug-ins (I'm assuming your CVS system will handle those changes easily.... but what about 3rd party modules??).

Anyway... This is going to be a fairly steep developer learning curve here.

You guys have had 6 months to deal with all the changes, and assimilate them. There's going to be a lag in the general community as far as understanding all the ins and outs.

Build::Build::build ('sub') is a clever deal. One build routine, that passes the passed parameter off as the internal subroutine.

Pet Peve #921 : The handling of Category fields.

Isn't there a more elegant way of doing this? For instance, assuming everything that is _NOT_ a predefined functional or control field, such as Name, Has_New_Links, ID, etc, _IS_ a parsable field?? And just iterate through the fields, doing the checking? That way all user added fields are automatically parsed?

hard-coding the category fields into the routine has been, IMHO, a kludge from day 1. People have started using additional fields in the categories for banners, dynamic includes, etc.

Some automated way of dealing with them should be implemented.


===

'isValidated', '=', 'Yes'

Gets rid of the "Validate" table, and I'm assuming (not having found it all in the code yet) that when the links are built, the program does an "AND isValidated='Yes', on all selects.

Does this mean that isValidated can be expanded to hold other values other than Yes and No? For instance, "Pending, OnHold, Dead, ReCheck" ?? If that field is flexible enough, ie: you are not using a binary 1/0 (empty/not-empty) check on it, couldn't it be used for other purposes??

This is a minor (exclusive flat) implementation of my glorious <G> flag-fields in my wish list;) for mutually non-exclusive flag settings using a binary mask, or set notation. I never was a good low-level programmer.

===




PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://postcards.com/FAQ

Hi pugdog,

Where are you looking at here?

Yes, it's Links::Build::build ('subroutine'). So to build a home page, it's Links::Build::build ('home'). This is part of the plugin system, as you can plug into any of these build features, before, after or override to change the functionality. The same thing for SiteHTML: Links::SiteHTML::display('link') is called to display a link.

921 of them? Wow. =) The code you mentioned is just for headers and footers. But I think what you are getting at is if someone adds a field to a category, it's not instantly available in the template like it would be for links. Yes, that has been addressed already with:

So any custom fields will automatically be added.

Correct. You could expand it to more, as the checks are all isValidated = 'Yes'. I did like your flags idea, but implementation was very difficult. It's still something I'd like to revisit.

Cheers,

Alex




--
Gossamer Threads Inc.

Alex, I never said I, or my brain, were easy <G>

The "hard coding" stems from the fact that you are using full library::module::function names for all the calls. This is a different approach than the use lib / use module format.

It does prevent name crashes, and such, but it also means that routine "get_category_name" can't be relocated from module_build to module_build_tools without making changes everywhere that sub/method is called.

That's all. Again, it's a logic change. I'm not making any other judgements about it, since that is really a better way of doing it for large projects, it just means more attention to libray::module::function naming has to be paid attention to if a change is made to the tree anywhere.

Yes, the handling of category fields are for header/footer files, but I've been in two situations now where people have wanted additional include file functioning based on the category. This would be things like sidebars, advertising, features, etc.

It would still be nice if all those fields were parsable, not just includable, and functioned like the header/footer fields.

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://postcards.com/FAQ