PEdit.inc.php rebuild

[q]

Beau, I'm opening this ticket until we've worked out all the glitches in PEdit.

Here's one: In PEdit.inc.php, this...

id="sc-pedit-<?php echo $name; ?>"

...should be changed to...

id="sc-pedit-field-<?php echo $name; ?>"

...or something similar to prevent the case where $name is "form" or some other conflicting title. Is this id="" used anywhere else?

[q]

PS: notice I reformatted the HTML/PHP source in PEdit.inc.php. The way you did it goes against the pear standard and is much harder to read. Hint: if the filename ends with .php then format it like PHP code.

[q]

Do these selectors need commas after their names? (from codebase.inc.css)

.sc-msg-warning
.sc-msg-error
.sc-msg-success
.sc-msg-notice {
	margin: 0 0 6px 0;
	padding: 5px;
	background: #fff;
	color: #f00;
	border: 1px solid #f00;
}

[beau]

Added commas - Changeset [102]

---

I'm not sure I agree with the pear standard.

My requirements:

• easy to read script code
• easy to read output code

I discussed this for hours (very light and fun... but serious) with Yann (french programmer) regarding the structure of template toolkit files. I had the same goals as above. We agreed that each set of code (html & tt) would have it's own indent structure. This is made easier by IDEs (TM, BBE, VI, etc) which all color the code.

True, HTML doesn't need to be pretty to work. However if you want to be able to troubleshoot it, pretty code is much easier to de-bug.

[q]

I disagree. Your suggestion of formatting is an issue of php vs html readability. I say it's most important to format in favor of php readability:

• It's much more important to be able to see bugs in PHP code. A bug in PHP can go undetected and may cause a severe server vulnerability, while HTML bugs will be detected by validators.
• HTML output can be automatically reformatted for readability using BBEdit, tidy, FF extention, etc. (No such tools exist for PHP code.)
• I consider it a waste of programmer time to bother formatting html source for readability when the tools will do it for you.
• It deviates from the codebase coding standards.

This holds true for any file that is predominately PHP (i.e. any file that ends with '*.php'). If a file is mostly HTML (ending with .html or .ihtml), HTML readability should take precidence. However, collapsed PHP code is still preferred. For example, the following:

<a href="<?php echo ohref(sprintf('/file.php?id=%s', $file_id), true); ?>">Click Here</a>

...is prefered over:

<a href="
<?php 
echo ohref(sprintf('/file.php?id=%s', $file_id), true);
?>
">Click Here</a>

[q]

I added the command classes (commandbox, commanditem, etc) that were deleted from utilities.inc.php into admin.inc.php since they are still used in the admin system.

[quinn]

I've updated all codebase utility classes with prepended sc- selectors. For example:

...
select.sc-medium { width: 20.5em; }

.sc-nowrap { white-space: nowrap; }
.sc-clearboth { clear: both; }
.sc-center { text-align: center; }

.sc-pkg { display: block; }

And globally searched-and-replaced all codebase files that use this format. This is so our usage of these utilities will never break or be broken by other sites that the codebase is integrated into.

Now I need to remember to do this for all current codebase 2.0 sites (lwstone, burb, golbonrfs, china-at-home) and my TM snippets.

I'm closing this ticket since I think everything has been wrapped up regarding PEdit. It seems to be working great! If there are any other issues we will open a new ticket.

[quinn]

This regex will convert an existing site to the new sc- format:

SEARCH:

class="([\w-]+ )*(tiny|small|medium|large|full|twolines|short|tall|fullscreen|nowrap|clearboth|center|right|padright|padleft|padleft|help|monospaced|pkg)( [\w-]+)*"

REPLACE:

class="$1sc-$2$3"

[anonymous]

​cheap wow gold

[anonymous]

​商标注册

[anonymous]

​除湿机

[anonymous]

about their apps in the first place. Both annotations and contributions will only clutter the interface by default as a design pattern rather than trying to put it all together. That way you can never create offline or print docs of high quality without again having the devs or current admins maintain the comments and annotations. Hopefully a small Wiki quality team will evolve (i am against ops or admins) to review and summarize the contributions. I hope this gives us more users as contributors than having the docs focused on the devs. Cheers, duns ​china tour ​Apparel ​shoes ​bags ​Kitchen ​Food and Wine ​Furniture) ​Flowers and Gifts ​Wall Art ​Computer Components I still prefer a wiki like approach since the php (or mysql) docs are very cluttered when you have to take their comments in account. On the other hand they are professionally maintained imho, since they are *much* better than KDE documentation. KDE is by far larger and has so many different apps, which need screenshots and end user not dev/api docs, that more help is needed as long as the devs prefer to code than to write nice docs. And it is their choice to some degree imo. Technically interested but non-dev end users, which are plenty out there, are the users of and the best contributers to the docs