21
Catzwolf
Re: Benefit of templates_c?
  • 2007/10/14 11:16

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


I never said because it is easier, I said because it separates presentation from logic. It means you the designer does not have to worry about the workings of the mechanics and deal with the presentation only if need be. There are many designers out there that don't programme with PHP and don't understand PHP and they feel uncomfortable working with PHP.

Forgive me, but I really don't understand the reason behind your argument, what you are suggesting is actually a step backwards, not forwards when it comes to design. You can pass information back and forth from php to html easily via Smarty without the need to have <?php My var ?> all over the place. Initially I believed your comments to be about the security implications of working with and html file? Also, Smarty does have [php][/php] tags that execute php. Allowing you to actually use PHP code, when and where you want within your template. So you have the functionality of PHP and the flexibility of smarty and html.

If you are referring to Joomla, trust me I have worked with Joomla, XOOPS 1.3 and other systems that use this method and I do not appreciate having to go into deep into a function in a faraway class just to change one line of html because of bad programming design. Yes, they do have better themes than us, I will agree with you on that. But I know that a majority of designers there have been demanding a templating system in Joomla for a long time (Actually 1.5 has addressed this issue). This is my own personal thoughts on the matter of Joomla and I personally dislike Joomla for that reason (Though Joomla has other things I really do like).

22
Catzwolf
Re: Benefit of templates_c?
  • 2007/10/14 11:38

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:

Will_H wrote:
@catz - you are half right. Of course I am worried about standards in the sense that everything should be iidentical, and easily accessible.

I <3 W3C


lol you had me worried then. I have never heard a designer yet who doesn't have a bee in his bonnet about this one.

Quote:

However, I am not interested in the force fed garbage that passes for standards in this community.


If you are referring to the xo- standards within Xoops? Well I am half and half about this approach, I suggest take what you can out of it and the other half leave it.

Quote:

I am behind Sublime on this. I have worked with JOOMLA! and pretty much every other CMS that can be slapped onto a nix box. Love em. Love XOOPS too, but over time I have ran into more and more "uhp, thats right... cant do that with XOOPS". than I care to mention.


Ok, Now we have to separate two things here and lets get straight about this subject. Are we talking about a developers stand point or a designers one? Because where I am standing from it sounds more like a developer one.

Are we talking about the flexibility there is in presenting the blocks (i.e.) moving them about where you want them to be? This rigid block structure with XOOPS Block positions? If so, this is not a Presentation failure but a logic failure and is something that the developers have to address. And actually, you could with smarty if you wanted do this under the current setup.

Quote:

The ultimate point is that designers do not have the option to mix the data & presentation layers if that is what they want to do.

We are forced and strong armed to utilize the Presentation layer, Its like mommy telling us to stay out of the cookie jar.

I just don't think that XOOPS is as flexible as it gives itself credit for. At least in this aspect.


Ok, look at it another way, how annoying is this? You are redesigning the look of a module and you change the templates and discover that the developer has hard coded a table of contents within the logic code. To find this code you then required to back track into the logic to actually find this part of the presentation. Surely this defeats the purpose of having logic and presentation separate.

Now, you the designer with smarty you are not limited to just design as I said to Sublime, you can use PHP within smarty anytime you like and where you like. In fact you go do this just as easily with XOOPS as you would with Joomla. [PHP]$a = array(0=>1,1=>2); foreach( $a AS $k => $v) { echo $k .' '.$v; }[/PHP]

As my example suggests, this is pure PHP and can be used within Smarty any time.

Now maybe I not understanding your guys needs here correctly, if so feel free to enlighten me and giving me, the developer a better understanding of your needs and hopefully changing something in the future.

ATB

Catz

23
Sublime
Re: Benefit of templates_c?
  • 2007/10/14 11:47

  • Sublime

  • Just popping in

  • Posts: 99

  • Since: 2006/5/23


Didn't notice the post you made before mine, I guess we were posting at the same time.

Quote:

catzwolf_ wrote:
I never said because it is easier, I said because it separates presentation from logic. It means you the designer does not have to worry about the workings of the mechanics and deal with the presentation only if need be. There are many designers out there that don't programme with PHP and don't understand PHP but they feel uncomfortable working with PHP.

I completely understand that quite a few people don't understand php and don't want to understand php, but I don't understand why that means that those of us that do understand it and are comfortable with it are unable to use it because of those people.

Quote:

Forgive me, but I really don't understand the reason behind your argument, what you are suggesting is actually a step backwards, not forwards when it comes to design. You can pass information back and forth from php to html easily via Smarty without the need to have <?php My var ?> all over the place. Initially I believed your comments to be about the security implications of working with and html file? Also, Smarty does have [php][/php] tags that execute php. Allowing you to actually use PHP code, when and where you want within your template. So you have the functionality of PHP and the flexibility of smarty and html.

My first post was an example of why I personally would prefer php over html, I should have probably made that more clear, that was my fault. The reason behind my argument is the frustration with limitations of the XOOPS template system and steps being made to further complicate a system which could be "de-complicated" simply by allowing a regular theme.php as well as a theme.html and implimenting a caching system that would actually cache php...that way those that don't understand php are free to use their smarty and html while those of us that do understand it can use straight php and accomplish more than we ever could with html...If you would like to know what limitations with the current template system I'm speaking of see skenow's post about what's being implemented in the 2.3 system in addition to many other things that I've come across that simply cant be done in the current template system. My point being that all of that could be solved with allowing php instead of further complicating the current system.

Quote:

If you are referring to Joomla, trust me I have worked with Joomla, XOOPS 1.3 and other systems that use this method and I do not appreciate having to go into deep into a function in a faraway class just to change one line of html because of bad programming design. Yes, they do have better themes than us, I will agree with you on that. But I know that a majority of designers there have been demanding a templating system in Joomla for a long time (Actually 1.5 has addressed this issue). This is my own personal thoughts on the matter of Joomla and I personally dislike Joomla for that reason (Though Joomla has other things I really do like).

No I was referring to phpNuke actually...nuke is a HORRIBLE CMS and is poorly coded, but the themes for it are outstanding. Try porting a high quality, well designed, feature filled nuke theme to xoops, you will find that you will have to leave out tons and tons of features simply because although the features are present in xoops, but you just cant do _insert_feature_here_ with the XOOPS template system.

24
wizanda
Re: Benefit of templates_c?
  • 2007/10/14 12:08

  • wizanda

  • Home away from home

  • Posts: 1585

  • Since: 2004/3/21


We basically need a way for the theme.html or theme.js in my own case, not to be read by any browser.....
It does make sense, in some ways....in others it is still possible to view the source code when it is rendered anyways, as i surf allot and look at page sources for ideas....

25
Catzwolf
Re: Benefit of templates_c?
  • 2007/10/14 12:31

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:

I completely understand that quite a few people don't understand php and don't want to understand php, but I don't understand why that means that those of us that do understand it and are comfortable with it are unable to use it because of those people.


This may sound like I am splitting hairs here, but I am not and trust me I will get to my point regarding this.

You are not actually talking about the templating system as a designer but more as a developer, yes there is a distinction between the two and a very real one. Most designers I know will tell you that they are not developers, never will be and wouldn’t know a line of PHP code if it came up and hit them.

Now there are many users of XOOPS who have a fair knowledge of HTML and can get by changing the templates to suit their needs without actually having to go anywhere near the code, unless to make small changes here and there and this is why the templating system was put in place. I was actually around at the time when this was happening and it was actually the designers at the time who where wanting this more than the developers.

You have stated that people with a better understanding of PHP cannot use this system? I am asking you flat out, what can’t you do with this system that you could with a php file? (Apart from the obvious of securing it like you have already mentioned?)

Quote:

The reason behind my argument is the frustration with limitations of the XOOPS template system and steps being made to further complicate a system which could be "de-complicated" simply by allowing a regular theme.php as well as a theme.html and implimenting a caching system that would actually cache php...that way those that don't understand php are free to use their smarty and html while those of us that do understand it can use straight php and accomplish more than we ever could with html...If you would like to know what limitations with the current template system I'm speaking of see skenow's post about what's being implemented in the 2.3 system in addition to many other things that I've come across that simply cant be done in the current template system. My point being that all of that could be solved with allowing php instead of further complicating the current system.


The limitations within the system are nothing to do with the Smarty engine but more the logic behind it. Most of my frustrations with XOOPS and its templates have nothing to do with the templates themselves but the actual coding behind it. Smarty does give me all the freedom in the world to express myself. As I have said, I can still mix logic and presentation if I wish with smarty and let smarty deal with it.

While I agree with you that the business logic behind the template system is to rigid, I do not believe that end method is wrong or not flexible enough by any means. I would be inclined to disagree about going back to a PHP only format for templating.

I will have a look at this post and read on the changes you have spoken about before saying anything more on this,

Quote:

Try porting a high quality, well designed, feature filled nuke theme to xoops, you will find that you will have to leave out tons and tons of features simply because although the features are present in xoops, but you just cant do _insert_feature_here_ with the XOOPS template system.


Could I have some examples of this please?

ATB

Catz

26
wizanda
Re: Benefit of templates_c?
  • 2007/10/14 12:48

  • wizanda

  • Home away from home

  • Posts: 1585

  • Since: 2004/3/21


Stop arguing catz please....from my impression he is disgruntled as someone stole his designs and easily as they can just copy a whole theme.html straight from out of the folder....

1) Yahoo uses Smarty (was reading)...
2) It isn't a question of who knows the most, yet can we make a system between us developers, to stop html themes being hijacked and designs stolen?

Personally was looking for ideas and if it is possible to scrambled the code unless read through Smarty and our own php systems....?

27
kaotik
Re: Benefit of templates_c?
  • 2007/10/14 12:56

  • kaotik

  • Just can't stay away

  • Posts: 861

  • Since: 2004/2/19


bottom line is no. A user will always be able to save a webpage to his computer and use that as a model. The only pages protected from this is flash pages.
If a user can see your page on his web browser, then he can save it.
Regarding template engines, I think smarty is far superior to PAT template being used in joomla. Try this simple test:
-open a smarty template in a wysiwyg editor, can you understand what's going on?
- now try opening a PAT template, can you understand it?
That's the advantage of smarty.
As Catzwolf has already stated you can still use php code inside a smarty template.
www.kaotik.biz

28
Catzwolf
Re: Benefit of templates_c?
  • 2007/10/14 13:16

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:

wizanda wrote:
Stop arguing catz please....from my impression he is disgruntled as someone stole his designs and easily as they can just copy a whole theme.html straight from out of the folder....

1) Yahoo uses Smarty (was reading)...
2) It isn't a question of who knows the most, yet can we make a system between us developers, to stop html themes being hijacked and designs stolen?

Personally was looking for ideas and if it is possible to scrambled the code unless read through Smarty and our own php systems....?


Who is arguing here? I think you need to reread my post again Wizanda.

We are discussing an issue regarding XOOPS templates and I have past the point on the security issue and now talking about the template engine and is it working for XOOPS or not.

29
Catzwolf
Re: Benefit of templates_c?
  • 2007/10/14 13:20

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:

kaotik wrote:
bottom line is no. A user will always be able to save a webpage to his computer and use that as a model. The only pages protected from this is flash pages.
If a user can see your page on his web browser, then he can save it.
Regarding template engines, I think smarty is far superior to PAT template being used in joomla. Try this simple test:
-open a smarty template in a wysiwyg editor, can you understand what's going on?
- now try opening a PAT template, can you understand it?
That's the advantage of smarty.
As Catzwolf has already stated you can still use php code inside a smarty template.


Hiya K,

Actually I was referring to just using a straight php file with html template inside. :)

OMG PAT, Don't even want to go near that template system. (Even Joomla dropped this in 1.5 as no one used it, well except the die hards).

ATB

Catz

30
Sublime
Re: Benefit of templates_c?
  • 2007/10/14 15:06

  • Sublime

  • Just popping in

  • Posts: 99

  • Since: 2006/5/23


Yes it's completely true that ultimately anyone can go to any website and take whatever they want, but do we have to make it so easy for them to do it is what I'm saying. And yes, wizanda is pretty much right, if you told me to list my reasoning to want to use php I would probably have "not quite as easy to rip" at the top.

Quote:
catzwolf_ wrote:
You have stated that people with a better understanding of PHP cannot use this system?

No i didn't say it was impossible for anyone with knowledge of php to use the system. I said I don't understand why everyone is forced to code exactly by that system simply because that is the standard that _whoever_ says you have to use. I've never experienced that with any other cms that I've used...

Quote:
catzwolf_ wrote:
I would be inclined to disagree about going back to a PHP only format for templating.

Again, I'm not saying drop the current system and go back to php only, the current system works just fine for whoever conforms to it. The only thing I'm asking is would it be all that difficult to accept direct php formatting as well considering php formatting works just fine for a plethora of other CMSs. That's a serious question.

@wizanda
Quote:
Personally was looking for ideas and if it is possible to scrambled the code unless read through Smarty and our own php systems....?

kinda off topic but: go tohttp://www.sublimedesign.org and View Source...notice the body.

Just an included function...which is fine for use on your own site but you really couldn't distribute it as it's likely to break a module that's heavy in javascript and someone told me before that Norton blocks that particular script, but I don't have Norton to confirm that...but yeah, it's possible...just threw that on to show ya.

Login

Who's Online

188 user(s) are online (124 user(s) are browsing Support Forums)


Members: 0


Guests: 188


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits