self-intro: Craig Sebenik

[Craig]

Steve Wendt wrote:
> On 7/18/2008 3:14 PM, Craig wrote:
> 
>> Also, several months ago, I proposed using autoconf, but met with
>> some resistance. *I* think using "./configure; make install" would be 
>> beneficial, but there is plenty of other stuff to do.
> 
> There's little to no benefit to that for scripted code, and it adds an 
> extra requirement.

I understand that. For installing on unix, there is almost no additional 
requirement. (I can't commit to "no additional requirement", but I am 
pretty sure that autoconf just generates a shell script. Which is 
probably going to be ok for 99.9% of unix systems. If I'm wrong, please 
let me know.) However, for development, adding things to the "install 
process" would be non-trivial. However, all of that can be made less 
painful with some scripts.

I see that adding there is little benefit in adding "./configure" to the 
current install process. But, I would argue that the current layout is 
not the best. Another *possible* way to lay it would be a more standard:
	html
	etc
	lib
	docs
	share (eg: share/templates)

Eg. it doesn't make a lot of sense to have a README sitting in the HTML 
directory. But, it also doesn't hurt anything, either. However, if you 
happen to forget to change httpd.conf to "AllowOverride", then someone 
could look at "localconfig" (as well as the rest of the .pl and .pm 
files). Yes, if this happens, that means the person that installed it 
made a mistake. But, mistakes happen.

I do realize how much work it would be to move everything into sub-dirs, 
but it really is a better layout for the long-term.

There would be some beneficial side-effects. Eg. if the perl modules 
were actually put into "/usr/lib/perl/site_perl/..." (or whatever), then 
it would be easier for end-users to write scripts. (This may be a "con"...)

Please don't misunderstand... I am not saying that I think the current 
method is totally "bad". I am just saying that there is another way that 
has a different set of pros and cons. However, the impact to the 
developers is far from 0.


>>   - more consistent use of "fielddefs".
>>     It seems like some "field titles" are hard coded into the
>>     templates... but, I could be wrong.
> 
> I think this is in an ongoing process of being fixed.  Others here know 
> better than I, I'm sure.

That's what I thought. After messing around with the code, it looks like 
it is an "in progress" thing. I am more than willing to help out with that.

>>   - move the help pages/data into the DB
> 
> It's much nicer (and easier) to link to online resources, that are 
> updated independently...


And it's 2 things you need to update. I recently had to update some of 
the help docs and it was a little confusing. There are the static help 
pages; template/en/default/pages/fields.html.tmpl, and the "roll overs" 
(eg. advanced search); template/en/default/search/search-help.html.tmpl.

Also, you have limited functionality with simply linking to a static 
file. One possible alternative would be a "popup window" for help 
instead of linking to a whole different page. (After all, if you really 
want help, going to another page and then hitting "back" is not always 
the desired user-experience.)

These are just some thoughts. I don't want to change things just to 
change them, I really think there are use cases that would show the 
benefits. I'd be happy to give a more thorough argument for the changes 
once I g become more familiar with the code itself. I am sure that some 
things will *seem* like they need to be changed, but once you understand 
why things are done a certain way, you see why it is so difficult to 
make some changes...

Craig