(@davidm: I’ll love to give it a try but I don’t know where I can download the branch)
I’m very surprised, I can’t understand at all
This is what I see here:
we
have a templating system we
trust, devs work on it, we
bet on it to do the critical work of presenting pages to users and spiders.
On the other hand, we insert into MODx another template engine because... well, the main argument here is "devs don’t need to focus on the template engine for the manager".
I still don’t see the point guys, the templating system is there now, it works, and working on it means strenghtening it and not loosing time!
When you say "you can even use the MODx templating sys, if you want", I still think the right sentence is viceversa: "You can even use Smarty, if you want".
Sincerely I don’t know my thoughts now: if the devs want to use Smarty, maybe I can think the DocumentParser is not that good.
But in this case, it’s not better to use Smarty at all?
Do you understand what I mean? It’s the approach to this decision that has a hole in its pattern. Or it’s good the DocumentParser, or Smarty. Can’t be either! They do the same identical thing! Do you realize it?
I can’t believe the same devs that created MODx aren’t able to productively re-use their code and are taking another engine to do the same thing their code has been written to do.
I don’t want to upset no one, I fully respect the devs and I don’t want to raise a chorus of "hey boy, we are the devs and you don’t develop the core so speak about your little snippets and take the core as we give it", but I’ve seen in MODx a new concept of CMS/CMF when I found it. MODx meant new solutions, new answers for old questions.
And now I read "we will use Smarty to render the manager". But Smarty is one of the OLD answers
. And it’s something we don’t have control on. What about Smarty upgrades? Will we have to keep 2 softwares updated and secured? Will you drop a MODx update everytime Smarty updates?
Will we need to learn to use Smarty to make a little modification of the manager (and only for that)?
Ok. Now we use Smarty for the backend because the devs don’t need to loose work. Tomorrow? We’ll switch to Smarty even for the frontend? I’m pretty sure, now. If it is loose work on the backend, it will even on the frontend.
If not, it will be a contradiction.
Wanna loose less time? Don’t play with Ext which looks cool but is absolutely not necessary. First because you’ve to arrange all the manager with it’s syntax and second because the more JS you add in the manager, the less we can customize it.
Better: completely strip out the JS from the manager. Live only the minimum to have the right click menu on the DocTree and the DocumentDirty function.
We all have lived for years without ajax and modal windows. Use CSS which is light and fast and extremely customizable, and go for a full page refresh. No one will cry because the menu has been refreshed with the page, nor the document tree.
Striping out the frames is the better thing you can do, and probably it’s the bigger step available.
-------
I write all this things about this question not because I’m against Smarty (well, sincerely if I prefered Smarty I’d have picked a Smarty powered CMF, and not MODx, but...) but because this can be a precedent. If improving such a big piece of MODx is loose time, why developing MODx templating sys is not loose time? Or the entire MODx! There are other OOP MVC CMF around. They use Smarty.
Instead of moving away from other CMFs to be the best one, are we going towards those?
ok, its enough, i’ll be quiet.
MODX Staff
MODX Staff
