Categories > TinyButStrong general >

Should we follow the trends?

The forum is closed. Please use Stack Overflow for submitting new questions. Use tags: tinybutstrong , opentbs
By: SoftExpert
Date: 2006-05-18
Time: 20:22

Should we follow the trends?

Hi everyone,

As you already know, Web 2.0 knocks at the doors now.
I wonder how difficult will it be to transform TBS into a heavy-duty framework that  follows the MVC concept , or at least, to make it a good choice for some frameworks out there ...
What will be the pros/cons for this matter?
Will it be relevant in the first place?

Thank you for your replies!

P.S.
Some food for thought:
http://cakephp.org/
http://www.codeigniter.com/
http://www.phpit.net/article/ten-different-php-frameworks/
http://www.phpwact.org/php/mvc_frameworks
By: TomH
Date: 2006-05-19
Time: 02:10

Re: Should we follow the trends?

Have you tried to do any real apps in TBS yet???

I'll take a shot at answer the underlying issue here...
IM(NSH)O, TBS is already a more 'heavy-duty' framework than some of the refs you cited.

In the TBS template engine (I'll call it a Framework) the 'template language' is head and shoulders above  the "View" component of the those cited.

The high-level flow processing logic of any serious application is the "Model" if you really need one

The TBS block-merge, block rendering logic, and subtemplate processing provides routines are an easy implemention of the "Controller" functions.

What else is there that's needed - except maybe adding all sorts of unceccesary complication.

Developers need to uses libraries/classes that match the type of solution that fits their clients needs -- not to make their client's solutions fit into some given architecture just for the sake of using one framework to solve all problems -- my 2 cents.

If you want to get fancy - then develop a plugin to help automate the handling of any particular functional module that you'd like. But, there are so many existing classes/libraries available that it's hardly essential.
By: Maz
Date: 2006-05-19
Time: 07:41

Re: Should we follow the trends?

"Developers need to uses libraries/classes that match the type of solution that fits their clients needs -- not to make their client's solutions fit into some given architecture just for the sake of using one framework to solve all problems -- my 2 cents."

Rarely has a truer word been spoken!

I couldn't agree more. Part of the real strength in TBS, as it stands today (especially true with the v3 plugin architecture) is its flexibility. Reading through past posts and comments, it's evidently clear to me at least that many people (myself included) chose TBS precisely because it didn't try to be all things to all people. I for one would really hate to see that change, especially when the reasons for doing so would be little more than just because its en vogue to do so.
By: Leo
Date: 2007-03-01
Time: 05:25

Re: Should we follow the trends?

I believe TBS can work as "V" side of some frameworks.
(In fact, thats the way I use it. And works fine)

TBS gives a faster and efficient View layer. Even better
than some framework's native "V".

(For example, the Zoop framework uses a templating
system (Smarty) as View. Some adjusts and TBS can
do it easier and faster.)
By: sheepy
Date: 2007-03-01
Time: 09:57

Re: Should we follow the trends?

It'd be easier to modify a framework to use TBS instead of making TBS into a framework.  Someone asked about TBS in CakePHP a while ago, for example.
By: SoftExpert
Date: 2007-03-01
Time: 10:42

Re: Should we follow the trends?

The main point for me was to "modularize" a bit TBS to allow dynamic inclusion/compilation of subclasses - making use of "lazy loading" concept. There has to be a way to reorganize the code : a part that handles the data, another that handles the HTML and another that handles the logic - some light MVC approach. I'm not saying that TBS is not good (I already used it in several projects and is by far the most flexible engine I ever used), but there could be a way to lower compilation costs - no use to load every time 100k lines of code.
As for integrating it  into a MVC framework, I did that too: http://www.codeigniter.com/wiki/TinyButStrong_Template_Engine/

So, would this benefit TBS or not?

By: sheepy
Date: 2007-03-02
Time: 11:57

Re: Should we follow the trends?

TBS already got a plugin system - there are  html plugin, OOo plugin, stat plugin...

To save real compilation cost, I find that opcode cache works better then selective loading.  Not to say modular is not good, but IMO TBS is not big enough to deserve further splitting.

Actually in my project the TBS and all its plugins are loaded as a whole, single module - either they are all loaded (lazily when called) or not loaded at all.  I decided that finer management or feature detection is not worth the cost, since I can only reliably save a few ms.