usebb-development — Development discussion

Re: [UseBB-Development] Threaded topics

[Dietrich M. <die...@us...>]

Dietrich Moerman schreef:
> posts 
> will have another post as a parent (instead of the topic in flat 
> forums). A "topic" entity will still exist (with one post reference, the 
> first one) in order to be able to sticky, lock, etc them.

Small adjustment, posts will still have a reference to the topic in 
order to be able to show them in a flat topic, though they will also 
have a reference to the parent post (which flat forum systems don't have).

For more information I refer to the domain model which I will have 
completed very soon.

-- 
Dietrich -- http://dmoerman.be

[UseBB-Development] Threaded topics

[Dietrich M. <die...@us...>]

Another idea I have discussed before on my old blog and the UseBB 
community. Please refer to

- http://www.usebb.net/community/topic-968.html
- http://dietrich.wordpress.com/2006/02/28/threaded-views/
- http://dietrich.wordpress.com/2006/03/04/threaded-views-2/

I will probably make UseBB 2 threaded. This means a rather important 
difference in database and class design compared to flat forums: posts 
will have another post as a parent (instead of the topic in flat 
forums). A "topic" entity will still exist (with one post reference, the 
first one) in order to be able to sticky, lock, etc them.

The reason for building this in UseBB is because it certainly may be an 
advantage in some cases, and threaded topics can be displayed as flat 
ones perfectly as well. You will have the possibility to switch between 
flat and threaded as in Phorum, vBulletin, etc.

-- 
Dietrich -- http://dmoerman.be

[UseBB-Development] Object-oriented and Namespace note

[Dietrich M. <die...@us...>]

This is more a small note, I read about the possibility of defining 
constants for language strings from an XML file and I'd like to note a 
few things for UseBB 2.

First of all, as you know, UseBB 2 is object oriented. This means all 
functionality and data is wrapped in classes, preferably separated as 
models (Topic, Forum), controllers (ViewTopic, ViewForum) and services 
(database access, Session). No or as less as possible regular functions 
should be defined in the global scope. The same goes for global 
constants. If any need to be defined, they should have the usebb_ or 
USEBB_ (for constants) prefix. However most constants will be defined as 
class constants where ofcourse no prefix is required.

Classes will as well have the UseBB_ prefix, this as a replacement for 
some basic namespace or package support that is still missing from PHP. 
The reason for using this prefix is to allow UseBB integration with 
other systems, a website, etc. By using a prefix we can rest assured no 
problems will rise with integrating.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] Translation system

[Joren de G. <jor...@gm...>]

To avoid conflicts you could also add a %  at the end of a parameter, like
%user% instead of %user. ;)
But it looks good to me.

2007/3/28, Dietrich Moerman <die...@us...>:
>
> Dietrich Moerman schreef:
> > Parameters will be numbered, so instead of using %s or %d, these will be
> > replaced with %1, %2, etc. If a translator requires the order of the
> > values to be changes, this can be done easily.
>
> I changed this while writing a part about the translation system in the
> summary document; it could be even better to name the parameters, for
> example %user and %views, this may be a bit easier to construct an array
> with keys and values instead of as method parameters.
>
> For example:
>
> UseBB_Lang::t('This topic was posted by %user and viewed %views times.',
> array(
>    'user' => $user->getName(),
>    'views' => $topic->getViews()
> ));
>
> --
> Dietrich -- http://dmoerman.be
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> UseBB-Development mailing list
> https://lists.sourceforge.net/lists/listinfo/usebb-development
>
> Unsubscribe quickly? Send "unsubscribe"
> to use...@li...
>



-- 
Google Gmail - www.gmail.com

Re: [UseBB-Development] Translation system

[Dietrich M. <die...@us...>]

Dietrich Moerman schreef:
> Parameters will be numbered, so instead of using %s or %d, these will be 
> replaced with %1, %2, etc. If a translator requires the order of the 
> values to be changes, this can be done easily.

I changed this while writing a part about the translation system in the 
summary document; it could be even better to name the parameters, for 
example %user and %views, this may be a bit easier to construct an array 
with keys and values instead of as method parameters.

For example:

UseBB_Lang::t('This topic was posted by %user and viewed %views times.', 
array(
   'user' => $user->getName(),
   'views' => $topic->getViews()
));

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] Translation system

[Dietrich M. <die...@us...>]

Joren de Graaf schreef:
> The way you describe it looks pretty convenient. Using XML for the
> translations could be a good idea too, but I'm not sure if most PHP installs
> have the SimpleXML module installed. 

SimpleXML is enabled by default in PHP 5.

> Lucky for me my current host does
> support it, and I use it for my configuration file. The scenario below
> outputs the tags as constants but it could be easily adapted for a
> translation system.
> Perhaps you could then also make it even more easy by specifying the default
> language strings in the class itself, and allow MOD writers to add their
> aditional language strings in say mods_English.xml.

The idea is to keep the English strings in the code... Mod writers are 
not required to perform any special actions, they just use 
UseBB_Lang::t() too and these strings may as well be translated.

If you would define all the strings in the class (with keys I presume) 
you get the same system as with v1, except for they will be embedded 
into a class instead of an array.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] Translation system

[Joren de G. <jor...@gm...>]

The way you describe it looks pretty convenient. Using XML for the
translations could be a good idea too, but I'm not sure if most PHP installs
have the SimpleXML module installed. Lucky for me my current host does
support it, and I use it for my configuration file. The scenario below
outputs the tags as constants but it could be easily adapted for a
translation system.
Perhaps you could then also make it even more easy by specifying the default
language strings in the class itself, and allow MOD writers to add their
aditional language strings in say mods_English.xml.

This is what I do:
         function configLoader($prefs){
            $file = simplexml_load_file($prefs);
// Load the simplexml function
            foreach($file->definition as $def) {
    // Load every 'definition' part
                eval("define('{$def->name}', '{$def->value}');");
// Output them as constants
            }
        }
And here is how I load it:
    class Portal{
        function __construct(){
            $this->configLoader('../data/config.xml');
        }
...
    }
config.xml:
<configuration>
...
   <definition>
        <name>TPL_PATH</name>
        <value>./sources/template/</value>
    </definition>
    <!-- Path to the emoticon directory -->
    <definition>
        <name>SMILE_PATH</name>
        <value>./images/smileys/</value>
    </definition>
    <!-- Status of the site, online = 1, offline = 0 -->
    <definition>
        <name>STATUS</name>
        <value>1</value>
    </definition>
...
</configuration>

2007/3/26, Dietrich Moerman <die...@us...>:
>
> Yet another post about a (re)new(ed) component in UseBB 2.
>
> I guess everybody here knows the current translation system in v1, a
> basic array with short explanatory keys and values which are passed to
> sprintf(). The strings thus contain occurrences of %s and %d to contain
> parameters.
>
> There are three problems with this system:
>
> a) *_English.php always needs to be up-to-date or the system will show
> Undefined index notices with new language variables.
>
> b) The order of the parameters cannot be changed, for example when two
> parameters are used, the order of the parameters in sprintf() is vital
> for which %s/%d occurrence is used in the string. Translators cannot
> change this order.
>
> c) The use of %d for numbers prohibits the use of thousand separators.
>
> For 2.0 I'd like to use a system alike to gettext, used in many Linux
> tools and programs (primarily C). However I will not use the gettext
> functionality in PHP, since it requires the translations to be compiled
> into .po files (AFAIK, correct me if I'm wrong) and gettext probably
> won't be available on most PHP installs. So, I will most likely
> implement this system in PHP.
>
> The idea is that the source code contains the full language strings
> instead of the short array indexes. For example, no $lang['Message'] but
> UseBB_Lang::t('Hello user.'); This overcomes the first problem, no
> language file will be needed for the English language and thus no
> outdated language file(s). This will also be easier for developers to
> "add" any strings. There is a downside though, see later.
>
> Parameters will be numbered, so instead of using %s or %d, these will be
> replaced with %1, %2, etc. If a translator requires the order of the
> values to be changes, this can be done easily.
>
> As a last item, since no %d and sprintf() is used anymore, there will be
> no problem in using thousands-separators.
>
> You have also noticed UseBB_Lang::t() will be used to form the
> translations. The simple reason for this is to keep the object oriented
> design (UseBB_ is a prefix that will always be used for classes). t() is
> a static method of UseBB_Lang and about the shortest method name I could
> think of. ;)
>
> A few more examples:
>
> UseBB_Lang::t('This topic was posted by %1 and viewed %2 times.',
> $user->getName(), $topic->getViews());
>
> The translation may look like:
>
> <string>
>         <source>This topic was posted by %1 and viewed %2 times.</source>
>         <translation>Dit onderwerp werd %2 keer bekeken en geplaatst door
> %1.</translation>
> </string>
>
> Note 1: I have used XML in this example, however I do not yet know how
> translation files could be implemented best. XML and the DOM is one
> possibility.
> Note 2: I have changed the order of the parameters in the translation to
> demonstrate this ability.
> Note 3: discover the downside here, since there will be no short indexes
> as with v1, changing only one character in the source string will cause
> the translation to be deprecated. However, if the English strings are
> written with enough care and double checked for mistakes, there should
> not really be a problem.
>
> A few things I have not yet thought about are how to implement
> thousand-separators and eventually how to treat singular/plural forms of
> the same string (apart from defining them separately).
>
> Any ideas, comments and additions are welcome.
>
> --
> Dietrich -- http://dmoerman.be
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> UseBB-Development mailing list
> https://lists.sourceforge.net/lists/listinfo/usebb-development
>
> Unsubscribe quickly? Send "unsubscribe"
> to use...@li...
>



-- 
Google Gmail - www.gmail.com

[UseBB-Development] Translation system

[Dietrich M. <die...@us...>]

Yet another post about a (re)new(ed) component in UseBB 2.

I guess everybody here knows the current translation system in v1, a 
basic array with short explanatory keys and values which are passed to 
sprintf(). The strings thus contain occurrences of %s and %d to contain 
parameters.

There are three problems with this system:

a) *_English.php always needs to be up-to-date or the system will show 
Undefined index notices with new language variables.

b) The order of the parameters cannot be changed, for example when two 
parameters are used, the order of the parameters in sprintf() is vital 
for which %s/%d occurrence is used in the string. Translators cannot 
change this order.

c) The use of %d for numbers prohibits the use of thousand separators.

For 2.0 I'd like to use a system alike to gettext, used in many Linux 
tools and programs (primarily C). However I will not use the gettext 
functionality in PHP, since it requires the translations to be compiled 
into .po files (AFAIK, correct me if I'm wrong) and gettext probably 
won't be available on most PHP installs. So, I will most likely 
implement this system in PHP.

The idea is that the source code contains the full language strings 
instead of the short array indexes. For example, no $lang['Message'] but 
UseBB_Lang::t('Hello user.'); This overcomes the first problem, no 
language file will be needed for the English language and thus no 
outdated language file(s). This will also be easier for developers to 
"add" any strings. There is a downside though, see later.

Parameters will be numbered, so instead of using %s or %d, these will be 
replaced with %1, %2, etc. If a translator requires the order of the 
values to be changes, this can be done easily.

As a last item, since no %d and sprintf() is used anymore, there will be 
no problem in using thousands-separators.

You have also noticed UseBB_Lang::t() will be used to form the 
translations. The simple reason for this is to keep the object oriented 
design (UseBB_ is a prefix that will always be used for classes). t() is 
a static method of UseBB_Lang and about the shortest method name I could 
think of. ;)

A few more examples:

UseBB_Lang::t('This topic was posted by %1 and viewed %2 times.', 
$user->getName(), $topic->getViews());

The translation may look like:

<string>
	<source>This topic was posted by %1 and viewed %2 times.</source>
	<translation>Dit onderwerp werd %2 keer bekeken en geplaatst door 
%1.</translation>
</string>

Note 1: I have used XML in this example, however I do not yet know how 
translation files could be implemented best. XML and the DOM is one 
possibility.
Note 2: I have changed the order of the parameters in the translation to 
demonstrate this ability.
Note 3: discover the downside here, since there will be no short indexes 
as with v1, changing only one character in the source string will cause 
the translation to be deprecated. However, if the English strings are 
written with enough care and double checked for mistakes, there should 
not really be a problem.

A few things I have not yet thought about are how to implement 
thousand-separators and eventually how to treat singular/plural forms of 
the same string (apart from defining them separately).

Any ideas, comments and additions are welcome.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] Template engine

[Joren de G. <jor...@gm...>]

I got it. I'll read it more closely tomorrow ;)
Martijn

2007/3/25, Dietrich Moerman <die...@us...>:
>
> Joren de Graaf schreef:
> > Hi Dietrich,
> > In response to what you said:
> > a)
> > Indeed, you still have to learn it, even though it is more assosiated
> with
> > HTML styled code, rather than PHP style code. And the real mayority of
> > people use HTML, in combination with a server side language or
> statically.
> > If users install the forum for the first time, and they don't know PHP,
> you
> > won't confuse them with totally different language. I have experienced
> this
> > myself when I first started coding.
>
> I don't see how it would be more like HTML code, in fact it looks more
> like BBCode to me (with the square brackets). I don't see how it would
> be more easy for people to learn this template system's syntax than
> basic PHP loops, if/else and method calls.
>
> >
> > a bis)
> > What you can do to tackle this is allowing people to set that custom
> > stylesheet in the forums' ACP (detecting them the same way templates are
> > currently detected, but filtered on .css extension. ( style.css,
> > style_blue.css, etc).
> > Then in the template header file you set it as a (TBS) variable or
> array.
> > Ofcourse this can be done with any solution. An TBS example could be:
> >           <link rel="stylesheet" type="text/css" href="
> [var..cst.TPL_PATH][
> > template.current]/[template.style]" media="screen" />
> > This would output as:
> >           <link rel="stylesheet" type="text/css"
> href="./templates/default /
> > style_mysite.css" media="screen"  />
> > for example. [template.xxxx] is a TBS block that holds the template
> > information (based on the current session or board configuration) as an
> > array. Everything after the dot is a array key.
>
> I wasn't doubting whether this is possible, but the point was that using
> this multi-stylesheet system less people will be tempted to edit any
> template files. People mostly only alter the CSS (and perhaps a few of
> the HTML code). With UseBB 1 you also couldn't edit any loops or
> conditionals since these were embedded in the core code, there were
> never any big complaints about this, and the people who wanted to change
> the template's structure edited the core PHP code anyway.
>
> >
> > b )
> > See this section <http://www.tinybutstrong.com/manual.php#php_oop> of
> the
> > TBS manual for OOP information.
>
> I see, however it seems TBS does not use the pull method but the push
> one since all objects need to be defined on the PHP side. Also, I don't
> see a way to call any static methods.
>
> >
> > c )
> > I'm not really sure if I understand this correctly.
> > But if you mean caching the template and storing it for a period of
> time,
> > TBS does come with such a solution.
> > You could add a detection page to check if the certain directories are
> > writable or not.
> > If not, could you explain this again? (I think you meant
> > compiling<http://www.tinybutstrong.com/description.php#compile>the
> > template).
>
> It could well be that you can compile TBS templates, but my point was
> that it isn't necessary to interpret, convert or cache any code when you
> use PHP based templates. If you use TBS and don't cache anything, your
> template will need to be interpreted every time. If you cache your
> templates, you end up with regular PHP templates (except for you didn't
> write them in PHP but in TBS syntax) in writable directories which need
> to be recached once you alter the template files.
>
> >
> > About PHP code in favor of Smarty(-style) code: I did read that.
> > Everyone favors a specific solution for his or her needs, so do I. Using
> PHP
> > code in templates is what I call dirty programming, and that's something
> > I've outgrown quite a while ago.
> > I preffer keeping my design and backend sepparated as much as possible,
> even
> > if it means it would need to process a bit longer (though I haven't
> noticed
> > any difference in processing time between TBS-parsing and PHP-plain
> parsing
> > in the form of a delay). TinyButStrong provides this: see the reasons
> > here<http://www.tinybutstrong.com/description.php>,
> > too.
>
> I don't see how it would be dirty programming, the only difference is
> that the TBS or Smarty syntax is replaced with PHP syntax. What concerns
> design and backend seperation, the backend are the models and
> controllers which are always seperated from the views in UseBB. The view
> does nothing but retrieving the data from the models, such as
> $topic->getTitle() or $topic->title. In TBS this would be
> [var.~topic.getTitle]. I don't see what the big difference is... except
> for you have to use foreach loops in PHP instead of difining blocks.
>
> >
> > Also, I thought that the name UseBB meant Usable Bulletin Board, right?
> > Shouldn't the usable part include templates, too?
> > Again, it's my view; you're the developer ;)
>
> The UseBB name was certainly not based on the word "usable", however
> usability is an important item. Although decisions need to be made
> concerning the inner workings. UseBB 2 using its OO models will be far
> more easy to use than UseBB 1's procedural code. The plugin system will
> allow the use of these models for modifications without changing any
> core code. And the multi-template system will allow someone only knowing
> HTML/CSS to alter the look of the forum. I think v2 goes far beyond the
> developer-side "usability" of v1.
>
> What concerns PHP based templates, I remain convinced this is the best
> solution with the least effort for both the developer and the system. In
> any case, this is just a decision about the default template parser. I
> still hope to be able to abstract the parser choice so one can develop a
> wrapper class for Smarty, TBS or any other system so templates can be
> developed in this system.
>
> In fact this is the exact same thing Drupal offers nowadays, default
> templates are using "phpTemplate" which are basic PHP based templates,
> but wrappers can be made for other template parsers (such as Smarty) to
> use Smarty templates (even without the need of having to change anything
> in the core Drupal code).
>
> As a last item, I'd like to link to
> http://www.phppatterns.com/docs/design/templates_and_template_engines
> which provides good information on this matter between template parsers
> and PHP templates.
>
> --
> Dietrich -- http://dmoerman.be
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> UseBB-Development mailing list
> https://lists.sourceforge.net/lists/listinfo/usebb-development
>
> Unsubscribe quickly? Send "unsubscribe"
> to use...@li...
>



-- 
Google Gmail - www.gmail.com

[UseBB-Development] Form API

[Dietrich M. <die...@us...>]

Hello all,

Since this is related to the template engine discussion in some way, I 
am posting this now.

Forms are a big problem with template engines, especially if they will 
need to be AJAX and plug-in enhanced as well. Think of a form for a poll 
where questions can be added "on-the-fly" (adding an input field and its 
containers) or a register form where XMLHttprequest is used to check if 
the entered user name is still available (idea courtesy of IPB) and a 
notice is added next to the input field's label. Or where a plug-in adds 
a certain input field ...

If template engines would have full power over these forms' elements and 
markup I think it would be nearly impossible to have them so flexible as 
in the above example. Therefore I opt for the usage of a form API as in 
Drupal.

The basic idea is that you can use an object oriented approach in the 
code to create a new form, add elements and their labels to it, add 
validators (analogue to ASP.NET) which make fields required, make them 
match regular expressions et al (these can be propagated to JavaScript 
as well to achieve client-side validation), etc...

(Note: Drupal uses an array based approach but since UseBB 2 will be 
object oriented, it will be achieved using classes and instances.)

A small example:

$form = new UseBB_Form('url', 'post');
$form->addElement(new UseBB_TextInput(1, UseBB_Lang::t('User name'), 
'username', '32'));
$form->addElement(new UseBB_Button(2, 'submit', UseBB_Lang::t('Submit 
form')));

This is a very simple example which creates a form with action="url" and 
method="post" and two elements
- a text field with weight 1, a User name label, name="username" and 
size="32"
- a button with weight 2, type="submit" and value="Submit form" (this 
value is translatable; note UseBB_Lang::t() is just a temporary example, 
I will elaborate on the translation system later).

This example is made entirely using constructor parameters, you could 
ofcourse as well use methods to set the properties of the elements, for 
example:

$userNameField->setDefaultValue(UseBB_Lang::t('Enter your username here.'));

The $form is later passed to the template where it can be put in the 
HTML code. This HTML will always be built up the same way and as 
semantic as possible, for example:

<form action="url" method="post">
   <dl>
     <dt><label for="username">User name</label></dt>
       <dd><input type="text" name="username" id="username" size="32" 
/></dd>
   </dl>
   <p><input type="submit" value="Submit form" /></p>
</form>

Ofcourse, the entire form can still be styled using CSS.

So, I hope I made this example a bit clear. I wanted to add an example 
of validation too but I haven't found out about doing that easily yet.

Your comments (or perhaps another and better solution?) are very welcome.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] Template engine

[Dietrich M. <die...@us...>]

Joren de Graaf schreef:
> Hi Dietrich,
> In response to what you said:
> a)
> Indeed, you still have to learn it, even though it is more assosiated with
> HTML styled code, rather than PHP style code. And the real mayority of
> people use HTML, in combination with a server side language or statically.
> If users install the forum for the first time, and they don't know PHP, you
> won't confuse them with totally different language. I have experienced this
> myself when I first started coding.

I don't see how it would be more like HTML code, in fact it looks more 
like BBCode to me (with the square brackets). I don't see how it would 
be more easy for people to learn this template system's syntax than 
basic PHP loops, if/else and method calls.

> 
> a bis)
> What you can do to tackle this is allowing people to set that custom
> stylesheet in the forums' ACP (detecting them the same way templates are
> currently detected, but filtered on .css extension. ( style.css,
> style_blue.css, etc).
> Then in the template header file you set it as a (TBS) variable or array.
> Ofcourse this can be done with any solution. An TBS example could be:
>           <link rel="stylesheet" type="text/css" href=" [var..cst.TPL_PATH][
> template.current]/[template.style]" media="screen" />
> This would output as:
>           <link rel="stylesheet" type="text/css" href="./templates/default /
> style_mysite.css" media="screen"  />
> for example. [template.xxxx] is a TBS block that holds the template
> information (based on the current session or board configuration) as an
> array. Everything after the dot is a array key.

I wasn't doubting whether this is possible, but the point was that using 
this multi-stylesheet system less people will be tempted to edit any 
template files. People mostly only alter the CSS (and perhaps a few of 
the HTML code). With UseBB 1 you also couldn't edit any loops or 
conditionals since these were embedded in the core code, there were 
never any big complaints about this, and the people who wanted to change 
the template's structure edited the core PHP code anyway.

> 
> b )
> See this section <http://www.tinybutstrong.com/manual.php#php_oop> of the
> TBS manual for OOP information.

I see, however it seems TBS does not use the pull method but the push 
one since all objects need to be defined on the PHP side. Also, I don't 
see a way to call any static methods.

> 
> c )
> I'm not really sure if I understand this correctly.
> But if you mean caching the template and storing it for a period of time,
> TBS does come with such a solution.
> You could add a detection page to check if the certain directories are
> writable or not.
> If not, could you explain this again? (I think you meant
> compiling<http://www.tinybutstrong.com/description.php#compile>the
> template).

It could well be that you can compile TBS templates, but my point was 
that it isn't necessary to interpret, convert or cache any code when you 
use PHP based templates. If you use TBS and don't cache anything, your 
template will need to be interpreted every time. If you cache your 
templates, you end up with regular PHP templates (except for you didn't 
write them in PHP but in TBS syntax) in writable directories which need 
to be recached once you alter the template files.

> 
> About PHP code in favor of Smarty(-style) code: I did read that.
> Everyone favors a specific solution for his or her needs, so do I. Using PHP
> code in templates is what I call dirty programming, and that's something
> I've outgrown quite a while ago.
> I preffer keeping my design and backend sepparated as much as possible, even
> if it means it would need to process a bit longer (though I haven't noticed
> any difference in processing time between TBS-parsing and PHP-plain parsing
> in the form of a delay). TinyButStrong provides this: see the reasons
> here<http://www.tinybutstrong.com/description.php>,
> too.

I don't see how it would be dirty programming, the only difference is 
that the TBS or Smarty syntax is replaced with PHP syntax. What concerns 
design and backend seperation, the backend are the models and 
controllers which are always seperated from the views in UseBB. The view 
does nothing but retrieving the data from the models, such as 
$topic->getTitle() or $topic->title. In TBS this would be 
[var.~topic.getTitle]. I don't see what the big difference is... except 
for you have to use foreach loops in PHP instead of difining blocks.

> 
> Also, I thought that the name UseBB meant Usable Bulletin Board, right?
> Shouldn't the usable part include templates, too?
> Again, it's my view; you're the developer ;)

The UseBB name was certainly not based on the word "usable", however 
usability is an important item. Although decisions need to be made 
concerning the inner workings. UseBB 2 using its OO models will be far 
more easy to use than UseBB 1's procedural code. The plugin system will 
allow the use of these models for modifications without changing any 
core code. And the multi-template system will allow someone only knowing 
HTML/CSS to alter the look of the forum. I think v2 goes far beyond the 
developer-side "usability" of v1.

What concerns PHP based templates, I remain convinced this is the best 
solution with the least effort for both the developer and the system. In 
any case, this is just a decision about the default template parser. I 
still hope to be able to abstract the parser choice so one can develop a 
wrapper class for Smarty, TBS or any other system so templates can be 
developed in this system.

In fact this is the exact same thing Drupal offers nowadays, default 
templates are using "phpTemplate" which are basic PHP based templates, 
but wrappers can be made for other template parsers (such as Smarty) to 
use Smarty templates (even without the need of having to change anything 
in the core Drupal code).

As a last item, I'd like to link to 
http://www.phppatterns.com/docs/design/templates_and_template_engines 
which provides good information on this matter between template parsers 
and PHP templates.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] Template engine

[Joren de G. <jor...@gm...>]

Hi Dietrich,
In response to what you said:
a)
Indeed, you still have to learn it, even though it is more assosiated with
HTML styled code, rather than PHP style code. And the real mayority of
people use HTML, in combination with a server side language or statically.
If users install the forum for the first time, and they don't know PHP, you
won't confuse them with totally different language. I have experienced this
myself when I first started coding.

a bis)
What you can do to tackle this is allowing people to set that custom
stylesheet in the forums' ACP (detecting them the same way templates are
currently detected, but filtered on .css extension. ( style.css,
style_blue.css, etc).
Then in the template header file you set it as a (TBS) variable or array.
Ofcourse this can be done with any solution. An TBS example could be:
          <link rel="stylesheet" type="text/css" href=" [var..cst.TPL_PATH][
template.current]/[template.style]" media="screen" />
This would output as:
          <link rel="stylesheet" type="text/css" href="./templates/default /
style_mysite.css" media="screen"  />
for example. [template.xxxx] is a TBS block that holds the template
information (based on the current session or board configuration) as an
array. Everything after the dot is a array key.

b )
See this section <http://www.tinybutstrong.com/manual.php#php_oop> of the
TBS manual for OOP information.

c )
I'm not really sure if I understand this correctly.
But if you mean caching the template and storing it for a period of time,
TBS does come with such a solution.
You could add a detection page to check if the certain directories are
writable or not.
If not, could you explain this again? (I think you meant
compiling<http://www.tinybutstrong.com/description.php#compile>the
template).

About PHP code in favor of Smarty(-style) code: I did read that.
Everyone favors a specific solution for his or her needs, so do I. Using PHP
code in templates is what I call dirty programming, and that's something
I've outgrown quite a while ago.
I preffer keeping my design and backend sepparated as much as possible, even
if it means it would need to process a bit longer (though I haven't noticed
any difference in processing time between TBS-parsing and PHP-plain parsing
in the form of a delay). TinyButStrong provides this: see the reasons
here<http://www.tinybutstrong.com/description.php>,
too.

Also, I thought that the name UseBB meant Usable Bulletin Board, right?
Shouldn't the usable part include templates, too?
Again, it's my view; you're the developer ;)

2007/3/25, Dietrich Moerman <die...@us...>:
>
> Joren de Graaf schreef:
> > Hi Dietrich,
> > I'm not sure how to reply to this message (doing it from Gmail).
> > But I've suggested the use of the
> > TinyButStrong< http://www.tinybutstrong.com/>template engine before on
> > the UseBB forums.
> >
> > At a first look this engine may seem very different and difficult but it
> > does in fact perform the same way of processing like Smarty does, only
> the
> > big differences between the two are that:
> > Smarty code is something like this:
> > <snip>
> >
> > This alows for much cleaner and smaller code to be written that does the
> > same thing the Smarty code does. Also, this code is much easier to be
> read
> > by users who don't know PHP. In adition to that, the code can also be
> viewed
> > in virtually any WYSIWYG editor.
> >
> > I think that this solution is deffinately worth looking at.
> > Good luck,
> > Martijn (martijn at UseBB forums)
>
> Hello,
>
> Thanks for your input, however as I said in this discussion I want to
> avoid any custom template syntax because
>
> a) even if it is simple, you will still need to learn it; except for PHP
> which I think many people already do;
>
> a bis) with the idea for multiple stylesheets in mind, people won't even
> have to edit the templates themselves to just alter colours (this is
> what most people do, the templates themselves are very seldom altered);
>
> b) not all engines provide an easy mechanism to interface with the model
> objects and others, for example, how will you be able to call an
> object's method or static method from within this template? It seems TBS
> does use the pull principle however I am not sure if it will give you
> the freedom of PHP code;
>
> c) all custom template syntaxes need to be interpreted and eventually
> converted and cached to PHP code, the result is that you get plain PHP
> code as with a PHP based templates, except for you have added a layer on
> top of it with a custom syntax which adds more processing time to the
> system (or writable directories to save the cache).
>
> The Smarty examples I used where just to illustrate the idea of loops
> and conditionals inside templates, later in the post I referred to the
> PHP syntax that can be used to achieve the same without having to
> interpret or convert any code.
>
> --
> Dietrich -- http://dmoerman.be
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> UseBB-Development mailing list
> https://lists.sourceforge.net/lists/listinfo/usebb-development
>
> Unsubscribe quickly? Send "unsubscribe"
> to use...@li...
>



-- 
Google Gmail - www.gmail.com

Re: [UseBB-Development] Template engine

[Dietrich M. <die...@us...>]

Joren de Graaf schreef:
> Hi Dietrich,
> I'm not sure how to reply to this message (doing it from Gmail).
> But I've suggested the use of the
> TinyButStrong<http://www.tinybutstrong.com/>template engine before on
> the UseBB forums.
> 
> At a first look this engine may seem very different and difficult but it
> does in fact perform the same way of processing like Smarty does, only the
> big differences between the two are that:
> Smarty code is something like this:
> <snip>
> 
> This alows for much cleaner and smaller code to be written that does the
> same thing the Smarty code does. Also, this code is much easier to be read
> by users who don't know PHP. In adition to that, the code can also be viewed
> in virtually any WYSIWYG editor.
> 
> I think that this solution is deffinately worth looking at.
> Good luck,
> Martijn (martijn at UseBB forums)

Hello,

Thanks for your input, however as I said in this discussion I want to 
avoid any custom template syntax because

a) even if it is simple, you will still need to learn it; except for PHP 
which I think many people already do;

a bis) with the idea for multiple stylesheets in mind, people won't even 
have to edit the templates themselves to just alter colours (this is 
what most people do, the templates themselves are very seldom altered);

b) not all engines provide an easy mechanism to interface with the model 
objects and others, for example, how will you be able to call an 
object's method or static method from within this template? It seems TBS 
does use the pull principle however I am not sure if it will give you 
the freedom of PHP code;

c) all custom template syntaxes need to be interpreted and eventually 
converted and cached to PHP code, the result is that you get plain PHP 
code as with a PHP based templates, except for you have added a layer on 
top of it with a custom syntax which adds more processing time to the 
system (or writable directories to save the cache).

The Smarty examples I used where just to illustrate the idea of loops 
and conditionals inside templates, later in the post I referred to the 
PHP syntax that can be used to achieve the same without having to 
interpret or convert any code.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] Template engine

[Joren de G. <jor...@gm...>]

I think this <http://www.tinybutstrong.com/article_3rd_kind.html> may
explain better then what I've written below.

2007/3/25, Joren de Graaf <jor...@gm...>:
>
> Hi Dietrich,
> I'm not sure how to reply to this message (doing it from Gmail).
> But I've suggested the use of the TinyButStrong<http://www.tinybutstrong.com/>template engine before on the UseBB forums.
>
> At a first look this engine may seem very different and difficult but it
> does in fact perform the same way of processing like Smarty does, only the
> big differences between the two are that:
> Smarty code is something like this:
> {foreach $posts as $post}
>        <h2>{$post->title}</h2> <p>{$post->content}</p>
> {/foreach}
> {if $user->loggedIn}
>        <p>Welcome back {$user->name}!</p>
> {else}
>        <p>Hello, please <a href="{... code to show register link
> ...}">register</a>!</p>
> {endif}
> (posted in another message of this mailing list.)
> -----------------
> TinyButStrong code looks like this (from my personal portal that
> interfaces with UseBB 1):
>             <div class="menucnt">
>                 <h3 class="wimg">[flang.UserPane]</h3>
>                 [onload_sess.level;block=div;when [var.sess.level] =0]
>                 <p style="font-size: 11pt;padding-left: 2px;">
>                     Welcome, [flang.Guest]!<br/>
>                     Please <a href="[var..cst.ROOT_PATH]panel- login.html">login</a>
> or <a href="[var..cst.ROOT_PATH]panel-register.html">register</a>.
>                 </p>
>             </div>
>             <div class="menucnt">
>                 <h3 class="wimg">[flang.UserPane]</h3>
>                 [onload_sess.level;block=div;when [var.sess.level] > 0 & <
> 3]
>                 <p style="font-size: 11pt;padding-left: 2px;margin-right:
> -2px">
>                     Welcome back, [var.sess.displayed_name]!<br/>
>                 </p>
>                 <ul>
>                     <li><a href="[var..cst.ROOT_PATH]panel-logout.html ">[
> flang.SiteLogOut]</a></li>
>                 </ul>
>             </div>
>             <div class="menucnt">
>                 <h3 class="wimg">[flang.UserPane ]</h3>
>                 [onload_sess.level;block=div;when [var.sess.level] = 3]
>                 <p style="font-size: 11pt;padding-left: 2px;">
>                     Welcome back, [var.sess.displayed_name ]!<br/>
>                     <span style="font-size: 10pt">Your last visit was on:
> <i>[var.sess.last_login;frm='dd mmmm yyyy']</i></span>
>                 </p>
>                 <ul>
>                     <li><a href="[var..cst.ROOT_PATH]panel-logout.html">[
> flang.SiteLogOut]</a></li>
>                     <li><a href="admin.php ">[flang.SiteAdminPane
> ]</a></li>
>                 </ul>
>
>             </div>
> ---------
>
> What the code above basically does is checking which user level the
> current user has (0-3: guest - admin) and displays the corresponding block,
> not parsing the other blocks. The {foreach} statement from Smarty is
> achieved by TBS by simply reading the 'block=' argument from the code.
>
> This alows for much cleaner and smaller code to be written that does the
> same thing the Smarty code does. Also, this code is much easier to be read
> by users who don't know PHP. In adition to that, the code can also be viewed
> in virtually any WYSIWYG editor.
>
> I think that this solution is deffinately worth looking at.
> Good luck,
> Martijn (martijn at UseBB forums)
>
> 2007/3/24, Dietrich Moerman < die...@us...>:
> >
> > Melissa schreef:
> > > I have never heard of XSLT; I'll have to take a look at it.
> >
> > XSLT is a system based on XML and XSL. The data passed to the template
> > is XML data and XSL code inside HTML is used to place the data in place.
> > This is the same as the push principle I explained before with a
> > template syntax that is somewhat standardised (XSL is a W3C
> > recommendation). However this requires PHP to have a XSLT parser enabled
> > all the time, and probably a whole bunch of extra processing time.
> >
> > --
> > Dietrich -- http://dmoerman.be
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net 's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > UseBB-Development mailing list
> > https://lists.sourceforge.net/lists/listinfo/usebb-development
> >
> > Unsubscribe quickly? Send "unsubscribe"
> > to use...@li...
> >
>
>
>
> --
> Google Gmail - www.gmail.com




-- 
Google Gmail - www.gmail.com

Re: [UseBB-Development] Template engine

[Joren de G. <jor...@gm...>]

Hi Dietrich,
I'm not sure how to reply to this message (doing it from Gmail).
But I've suggested the use of the
TinyButStrong<http://www.tinybutstrong.com/>template engine before on
the UseBB forums.

At a first look this engine may seem very different and difficult but it
does in fact perform the same way of processing like Smarty does, only the
big differences between the two are that:
Smarty code is something like this:
{foreach $posts as $post}
       <h2>{$post->title}</h2> <p>{$post->content}</p>
{/foreach}
{if $user->loggedIn}
       <p>Welcome back {$user->name}!</p>
{else}
       <p>Hello, please <a href="{... code to show register link
...}">register</a>!</p>
{endif}
(posted in another message of this mailing list.)
-----------------
TinyButStrong code looks like this (from my personal portal that interfaces
with UseBB 1):
            <div class="menucnt">
                <h3 class="wimg">[flang.UserPane]</h3>
                [onload_sess.level;block=div;when [var.sess.level] =0]
                <p style="font-size: 11pt;padding-left: 2px;">
                    Welcome, [flang.Guest]!<br/>
                    Please <a
href="[var..cst.ROOT_PATH]panel-login.html">login</a>
or <a href="[var..cst.ROOT_PATH]panel-register.html">register</a>.
                </p>
            </div>
            <div class="menucnt">
                <h3 class="wimg">[flang.UserPane]</h3>
                [onload_sess.level;block=div;when [var.sess.level] > 0 & <
3]
                <p style="font-size: 11pt;padding-left: 2px;margin-right:
-2px">
                    Welcome back, [var.sess.displayed_name]!<br/>
                </p>
                <ul>
                    <li><a href="[var..cst.ROOT_PATH]panel-logout.html">[
flang.SiteLogOut]</a></li>
                </ul>
            </div>
            <div class="menucnt">
                <h3 class="wimg">[flang.UserPane]</h3>
                [onload_sess.level;block=div;when [var.sess.level] = 3]
                <p style="font-size: 11pt;padding-left: 2px;">
                    Welcome back, [var.sess.displayed_name]!<br/>
                    <span style="font-size: 10pt">Your last visit was on:
<i>[var.sess.last_login;frm='dd mmmm yyyy']</i></span>
                </p>
                <ul>
                    <li><a href="[var..cst.ROOT_PATH]panel-logout.html">[
flang.SiteLogOut]</a></li>
                    <li><a href="admin.php">[flang.SiteAdminPane]</a></li>
                </ul>

            </div>
---------

What the code above basically does is checking which user level the current
user has (0-3: guest - admin) and displays the corresponding block, not
parsing the other blocks. The {foreach} statement from Smarty is achieved by
TBS by simply reading the 'block=' argument from the code.

This alows for much cleaner and smaller code to be written that does the
same thing the Smarty code does. Also, this code is much easier to be read
by users who don't know PHP. In adition to that, the code can also be viewed
in virtually any WYSIWYG editor.

I think that this solution is deffinately worth looking at.
Good luck,
Martijn (martijn at UseBB forums)

2007/3/24, Dietrich Moerman <die...@us...>:
>
> Melissa schreef:
> > I have never heard of XSLT; I'll have to take a look at it.
>
> XSLT is a system based on XML and XSL. The data passed to the template
> is XML data and XSL code inside HTML is used to place the data in place.
> This is the same as the push principle I explained before with a
> template syntax that is somewhat standardised (XSL is a W3C
> recommendation). However this requires PHP to have a XSLT parser enabled
> all the time, and probably a whole bunch of extra processing time.
>
> --
> Dietrich -- http://dmoerman.be
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> UseBB-Development mailing list
> https://lists.sourceforge.net/lists/listinfo/usebb-development
>
> Unsubscribe quickly? Send "unsubscribe"
> to use...@li...
>



-- 
Google Gmail - www.gmail.com

Re: [UseBB-Development] Template engine

[Dietrich M. <die...@us...>]

Melissa schreef:
> I have never heard of XSLT; I'll have to take a look at it.

XSLT is a system based on XML and XSL. The data passed to the template 
is XML data and XSL code inside HTML is used to place the data in place. 
This is the same as the push principle I explained before with a 
template syntax that is somewhat standardised (XSL is a W3C 
recommendation). However this requires PHP to have a XSLT parser enabled 
all the time, and probably a whole bunch of extra processing time.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] Template engine

[Dietrich M. <die...@us...>]

Rick Pastoor schreef:
> Hi Ditrich,
> 
> I would like to add some notes about template engines.
> 
> I looked into the current template engine, which is based on php-formatted
> templates. For me this has one big advantage, because it supports multiple
> templates into one file, this greatly reduces the amount of templates with 3
> lines of html. However, the disadvantage is that for people that do not know
> php and just want to intergrate UseBB into their projects have to go and
> edit php files, which can be an obstacle. Another disadvantage is the use of
> php within the templates, wich is obviously not possible while using html
> based templates. (This can be a positive thing about php based templates
> ofcourse) One more thing is that if you do not use php within your
> templates, you keep your syntax-highlightning within your favorite editor,
> which is nice :)
> 
> As you can see, right now I prefer html based templates. What is your
> opinion on this topic? If there are other people that want to discuss this,
> please do :)
> 
> Rick

Hello,

First of all about the current system in v1. The templates are nothing 
but HTML strings with {variables} and {l_LanguageVariables}, these are 
packed into an array per "section" (ie a topic, a forum list, etc). As 
there are no conditionals or loops in the templates themselves, I had to 
break up the templates in these separate strings in order to process the 
loops in the PHP code itself.

For example, a topic has the template string "topic_header", 
"topic_post" and "topic_footer". The PHP code first processes 
topic_header, then processes all the topic_posts while looping through 
the posts' query result set and ends with parsing topic_footer. Now 
processing the repeated HTML blocks is a task for the inner code.

Advantage? Templates are extremely simple when you know which 
{variables} are passed to which template string (all {l_*} style 
language variables are always available). The reason for keeping the 
string per section in one file is because less files need to be included.

Disadvantages? You are limited to what variables the PHP code passes to 
you. If there's something you'd like to do in a specific string (even 
just displaying the current date), you will most likely have to edit the 
core PHP code and add the variable. Also, you cannot use conditionals. 
For example, you cannot alter your template to contain a check to 
display either "Hello $user!" or "Hello guest, please register!" based 
on whether the visitor is logged in. This will also have to be added in 
the PHP code and passed to a variable. This is what some variables do at 
this point (for example the Register/Your Panel link).

So, there are two problems:
a) push vs. pull principle, the template code itself can't decide itself 
which data is used in the template, the PHP code decides (push principle);

b) no conditionals/loops, again the PHP code is the only one deciding 
about loops and conditionals.

The solution I have in mind is:
a) use the pull principle, the template code can decide for itself what 
data is retrieved from the system (by means of using the data models 
that are passed to it and all other services available). For example, 
{$topic->title} (or using PHP syntax, see later) or {$user->language}.

b) use inner conditionals and loops, the template code itself contains 
the loop and loops over the (for example) array of posts it retrieves:

{foreach $posts as $post}
	<h2>{$post->title}</h2> <p>{$post->content}</p>
{/foreach}

(again, this may be PHP syntax as well, see later). It may also decide 
for itself about conditionals (up to some point), for example:

{if $user->loggedIn}
	<p>Welcome back {$user->name}!</p>
{else}
	<p>Hello, please <a href="{... code to show register link 
...}">register</a>!</p>
{endif}

Now the template editor has almost full power over what he/she can use. 
Also, there will be no reason anymore to break up templates as you said, 
a "topic" will only have one complete template since loops will be 
integrated.

Now, I'd like to use PHP based templates, this means no custom syntax is 
used in the template code (as in the above examples). For example, the 
last code would be:

<?php if ( $user->loggedIn ): ?>
	<p>Welcome back <?php print $user->name; ?>!</p>
<?php else: ?>
	<p>Hello, please <a href="<?php ... ?>">register</a>!</p>
<?php endif; ?>

The advantage is that, as opposed to other template syntax as with 
Smarty, no conversion is needed and thus there is no point in having to 
cache anything (Smarty caches are just PHP templates, which is what we 
use). The "disadvantage" is that you will need to know PHP. However, if 
Smarty or another syntax is used, you will have to know that as well.

It also seems the PHP code is bigger, but this is a false statement, 
since the converted or cached Smarty (for example) code will be the same 
PHP syntax with probably the same size.

What concerns syntax highlighting, there will be no problem editing 
regular PHP template files, even using HTML with embedded PHP (this is 
what most PHP code looks like nowadays).

Additionally to this idea, I would still like two things:

a) able the use of multiple CSS style sets for one template set. Thus, 
you should be able to create a different CSS style for the same template 
code. With v1 many people copy over the entire default template set to 
just alter the .css file. This will not be needed anymore.

b) able the use of different template engines, apart from the default 
PHP based one. For example, it should be possible to create a wrapper 
for Smarty and use Smarty based templates when you would like to.

So, I hope I have cleared it up a bit.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] Template engine

[Melissa <uns...@gm...>]

Well, if you can't find a template system that will keep up-to-date with
UseBB development, then really, you may end up with more problems then
solutions when trying to implement it in later releases.

I have never heard of XSLT; I'll have to take a look at it.



On 3/23/07, Rick Pastoor <ric...@gm...> wrote:
>
> Hi Ditrich,
>
> I would like to add some notes about template engines.
>
> I looked into the current template engine, which is based on php-formatted
> templates. For me this has one big advantage, because it supports multiple
> templates into one file, this greatly reduces the amount of templates with
> 3
> lines of html. However, the disadvantage is that for people that do not
> know
> php and just want to intergrate UseBB into their projects have to go and
> edit php files, which can be an obstacle. Another disadvantage is the use
> of
> php within the templates, wich is obviously not possible while using html
> based templates. (This can be a positive thing about php based templates
> ofcourse) One more thing is that if you do not use php within your
> templates, you keep your syntax-highlightning within your favorite editor,
> which is nice :)
>
> As you can see, right now I prefer html based templates. What is your
> opinion on this topic? If there are other people that want to discuss
> this,
> please do :)
>
> Rick
>
> -----Oorspronkelijk bericht-----
> Van: use...@li...
> [mailto:use...@li...] Namens Dietrich
> Moerman
> Verzonden: vrijdag 23 maart 2007 23:54
> Aan: UseBB development mailing list
> Onderwerp: [UseBB-Development] Template engine
>
> Initially, I chose to use Savant for 2.0 since it is PHP 5 compatible,
> uses
> PHP template blocks (does not require compilation or conversions) and is
> quite light. However no updates have been done on Savant, the latest PHP 5
> version is still "3.0.0". So I think Savant isn't a good idea after all.
>
> I have been doubting for a couple of weeks whether it would still be
> advantageous to look for a 3rd party template engine instead of writing
> our
> own one that is small, uses PHP based templates and can be integrated
> perfectly. It will add another x weeks (or perhaps not) of work to the
> complete development time but it may be worth it.
>
> An XSLT based system was also mentioned on the forums, but I don't know
> for
> sure if it is enabled in PHP 5.2 by default now, and if it is whether many
> hosts have it themselves. I also think it will take quite a few more
> processing time and more time for people unskilled with XSL to develop
> templates. So I would keep XSLT as an idea or extension for later
> versions.
>
> --
> Dietrich -- http://dmoerman.be
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
> Techsay panel and you'll get the chance to share your opinions on IT &
> business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> UseBB-Development mailing list
> https://lists.sourceforge.net/lists/listinfo/usebb-development
>
> Unsubscribe quickly? Send "unsubscribe"
> to use...@li...
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> UseBB-Development mailing list
> https://lists.sourceforge.net/lists/listinfo/usebb-development
>
> Unsubscribe quickly? Send "unsubscribe"
> to use...@li...
>

Re: [UseBB-Development] Template engine

[Rick P. <ric...@gm...>]

Hi Ditrich,

I would like to add some notes about template engines.

I looked into the current template engine, which is based on php-formatted
templates. For me this has one big advantage, because it supports multiple
templates into one file, this greatly reduces the amount of templates with 3
lines of html. However, the disadvantage is that for people that do not know
php and just want to intergrate UseBB into their projects have to go and
edit php files, which can be an obstacle. Another disadvantage is the use of
php within the templates, wich is obviously not possible while using html
based templates. (This can be a positive thing about php based templates
ofcourse) One more thing is that if you do not use php within your
templates, you keep your syntax-highlightning within your favorite editor,
which is nice :)

As you can see, right now I prefer html based templates. What is your
opinion on this topic? If there are other people that want to discuss this,
please do :)

Rick

-----Oorspronkelijk bericht-----
Van: use...@li...
[mailto:use...@li...] Namens Dietrich
Moerman
Verzonden: vrijdag 23 maart 2007 23:54
Aan: UseBB development mailing list
Onderwerp: [UseBB-Development] Template engine

Initially, I chose to use Savant for 2.0 since it is PHP 5 compatible, uses
PHP template blocks (does not require compilation or conversions) and is
quite light. However no updates have been done on Savant, the latest PHP 5
version is still "3.0.0". So I think Savant isn't a good idea after all.

I have been doubting for a couple of weeks whether it would still be
advantageous to look for a 3rd party template engine instead of writing our
own one that is small, uses PHP based templates and can be integrated
perfectly. It will add another x weeks (or perhaps not) of work to the
complete development time but it may be worth it.

An XSLT based system was also mentioned on the forums, but I don't know for
sure if it is enabled in PHP 5.2 by default now, and if it is whether many
hosts have it themselves. I also think it will take quite a few more
processing time and more time for people unskilled with XSL to develop
templates. So I would keep XSLT as an idea or extension for later versions.

--
Dietrich -- http://dmoerman.be

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
Techsay panel and you'll get the chance to share your opinions on IT &
business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
UseBB-Development mailing list
https://lists.sourceforge.net/lists/listinfo/usebb-development

Unsubscribe quickly? Send "unsubscribe"
to use...@li...

[UseBB-Development] Template engine

[Dietrich M. <die...@us...>]

Initially, I chose to use Savant for 2.0 since it is PHP 5 compatible, 
uses PHP template blocks (does not require compilation or conversions) 
and is quite light. However no updates have been done on Savant, the 
latest PHP 5 version is still "3.0.0". So I think Savant isn't a good 
idea after all.

I have been doubting for a couple of weeks whether it would still be 
advantageous to look for a 3rd party template engine instead of writing 
our own one that is small, uses PHP based templates and can be 
integrated perfectly. It will add another x weeks (or perhaps not) of 
work to the complete development time but it may be worth it.

An XSLT based system was also mentioned on the forums, but I don't know 
for sure if it is enabled in PHP 5.2 by default now, and if it is 
whether many hosts have it themselves. I also think it will take quite a 
few more processing time and more time for people unskilled with XSL to 
develop templates. So I would keep XSLT as an idea or extension for 
later versions.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] UseBB (2.0) introduction document

[Dietrich M. <die...@us...>]

Melissa schreef:
> Though, with the regards to changing the programming language for v3.0, I'm
> not overally sure about that one. If you decided to just maybe expand the
> code base to other languages while still developing in PHP primarily, that
> would be very impressive. Though, as I am decently versed in PHP, in regards
> to other languages, I am quite a biased opinion.

It's still a rough idea and certainly open for discussion. If UseBB 2.0 
manages to build up a fair community, there won't really be an 
opportunity to just switch programming languages. However a side project 
for UseBB in Java (or Python, Ruby, perhaps VB/C#.NET) could certainly 
be interesting.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] UseBB (2.0) introduction document

[Dietrich M. <die...@us...>]

Rick Pastoor schreef:
> One thing I
> like about this project is that you are professional enough to see (and
> confirm) some design-flaws

This is one big difference with 2003 when I started UseBB 1.0, it was 
more an experiment and opportunity to get to know PHP better. After 
three and a half years I guess I have learnt and worked with other 
languages and packages enough to develop 2.0 without the problems of 
1.0. I have also talked on the forums about halting 0.x's development 
before 1.0 was released as I knew there were design flaws... but it was 
eventually still completed. :)

> and this time are willing to let other people
> contribute to the design and so on. I hope to get more of a discussion here
> at the mailing list, and would like to contribute where possible.

Previously, there wasn't really a design phase for 1.0, after all "we" 
were still very unknown (as we still are, however). This time I will 
indeed try to post some of the work I have completed so any changes can 
be applied based on feedback. However the actual code will remain secret 
until 1.99.

-- 
Dietrich -- http://dmoerman.be

Re: [UseBB-Development] UseBB (2.0) introduction document

[Melissa <uns...@gm...>]

Very nice document Dietrich. I'm really looking forward to the plug-in/hook
system, it will certainly add to UseBB2's popularity. I myself have never
really used CVS or SVN so I can't really comment on that aspect of anything.

Though, with the regards to changing the programming language for v3.0, I'm
not overally sure about that one. If you decided to just maybe expand the
code base to other languages while still developing in PHP primarily, that
would be very impressive. Though, as I am decently versed in PHP, in regards
to other languages, I am quite a biased opinion.

On 3/22/07, Rick Pastoor <ric...@gm...> wrote:
>
> Hi all,
>
> I guess this is a very nice document, with clear information for us all. I
> am very pleased to read that UseBB is going to shift to SVN, I have far
> more
> good experiences with SVN than with CVS, so that will be nice :) One thing
> I
> like about this project is that you are professional enough to see (and
> confirm) some design-flaws, and this time are willing to let other people
> contribute to the design and so on. I hope to get more of a discussion
> here
> at the mailing list, and would like to contribute where possible.
>
> Yours,
>
> Rick
>
> -----Oorspronkelijk bericht-----
> Van: use...@li...
> [mailto:use...@li...] Namens Dietrich
> Moerman
> Verzonden: donderdag 22 maart 2007 19:58
> Aan: use...@li...
> Onderwerp: [UseBB-Development] UseBB (2.0) introduction document
>
> This is the first version of the summary document for the UseBB project.
> It consists of a small introduction on the project, UseBB 1.0 (including
> strengths, weaknesses and design flaws), UseBB 2.0 (the new website and
> forum package) and a small brainstorm for the future (UseBB 3.0). This
> document will be redistributed with the final release.
>
> Any comments, additions, etc are welcome.
>
> --
> Regards,
> Dietrich Moerman
> UseBB Project Manager
> http://www.usebb.net
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> UseBB-Development mailing list
> https://lists.sourceforge.net/lists/listinfo/usebb-development
>
> Unsubscribe quickly? Send "unsubscribe"
> to use...@li...
>

Re: [UseBB-Development] UseBB (2.0) introduction document

[Rick P. <ric...@gm...>]

Hi all,

I guess this is a very nice document, with clear information for us all. I
am very pleased to read that UseBB is going to shift to SVN, I have far more
good experiences with SVN than with CVS, so that will be nice :) One thing I
like about this project is that you are professional enough to see (and
confirm) some design-flaws, and this time are willing to let other people
contribute to the design and so on. I hope to get more of a discussion here
at the mailing list, and would like to contribute where possible.

Yours,

Rick 

-----Oorspronkelijk bericht-----
Van: use...@li...
[mailto:use...@li...] Namens Dietrich
Moerman
Verzonden: donderdag 22 maart 2007 19:58
Aan: use...@li...
Onderwerp: [UseBB-Development] UseBB (2.0) introduction document

This is the first version of the summary document for the UseBB project. 
It consists of a small introduction on the project, UseBB 1.0 (including
strengths, weaknesses and design flaws), UseBB 2.0 (the new website and
forum package) and a small brainstorm for the future (UseBB 3.0). This
document will be redistributed with the final release.

Any comments, additions, etc are welcome.

--
Regards,
Dietrich Moerman
UseBB Project Manager
http://www.usebb.net

[UseBB-Development] UseBB (2.0) introduction document

[Dietrich M. <die...@us...>]

This is the first version of the summary document for the UseBB project. 
It consists of a small introduction on the project, UseBB 1.0 (including 
strengths, weaknesses and design flaws), UseBB 2.0 (the new website and 
forum package) and a small brainstorm for the future (UseBB 3.0). This 
document will be redistributed with the final release.

Any comments, additions, etc are welcome.

-- 
Regards,
Dietrich Moerman
UseBB Project Manager
http://www.usebb.net