« This describes me somewhat
Wedge templating for designers
Remove flash dependency from AeMe? »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Wedge templating for designers
« Reply #15, on February 2nd, 2013, 10:23 PM »
Here's the thing about threaded mode... by definition you really need a 'reply to this message' button which would cover that, not fudging it through anything else. It's going to get confusing if people press to reply to something and it isn't conjoined on the page (e.g. pressing a button only to have to go back to the bottom to reply)

A popup reply would solve that, even as an overlay of some kind.

This is ultimately why threaded mode causes trouble because of the multitude of UI parts to it.
Quote
My goal is precisely the same: making mods/plugins work together without limiting each other.
Isn't possible.
Quote
My beef with SMF is that mods have always taken precedence, while ideally it should be equal.
Not from SMF's point of view. From the user's point of view, perhaps. They just want it all to work and don't have to care about it. It wasn't until 2.0/2.1 that SMF had anything like features that could support this, and even then SMF doesn't have enough to do it properly, not even in 2.1.
Quote
Mods add features, themes adds design, the two should not interfere..and the theme engine will be the glue between those two.
Missing the point.

Mods add features, they have to remember to use the right markup - i.e. working to the theme. If you look back through everything we've done, mods are actually more constrained than themes are, by design, to account for this sort of problem. And even we haven't nailed it entirely.
Quote
So having mods just go right in and change templates are a bad thing, and course themes not rendering mod's output equally bad.
Which is exactly why they have to work together. Not be separate and glued together. They have to make some compromises, no matter how you might wish otherwise. And bear in mind, this isn't theoretical, most of this stuff works already. As shown on this very site - there are multiple plugins here that integrate just fine.
Quote
What I do want though is that plugins also *just work*..but ultimately the theme makes them look great. Binding the HTML+CSS in such a way that the theme cannot reach them is a then a dead end IMO. But I have no definite answers to how to get there..only ideas to try out.
What you're saying is what you've been saying since this conversation started, that the theme has total control. That's fine, all the time plugins don't want to do anything outlandish or in any way imaginative because then they're screwed because they're bound to what the theme actually lets them do. For it to work in any practical fashion there must be compromise, not total control in one direction or the other.

I wouldn't want to write plugins for your setup because they don't give me any freedom in how I design any of it. In your setup, for example, SimpleDesk would have had to use the same layout as given by anything else, which doesn't work because it had its own requirements in terms of content and presentation. This is why the plugin has to have *some* control over what it's doing.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial
Re: Re : Wedge templating for designers
« Reply #16, on February 2nd, 2013, 11:02 PM »
Quote from Nao on February 2nd, 2013, 09:00 PM
Quote from Bloc on February 2nd, 2013, 05:21 PM
What I meant with Elkarte/SMF 2.1 was that they added specifically two functions that call javascript and css, thereby making a bit impossible to override any mods output of those,
I remember seeing loadJavaScriptFile and loadCSSFile functions in their codebase, but couldn't be arsed to find out what they did in comparison to our own add_css_file and add_js_file functions. (Except of course Wedge gets to minify, compress and cache the files automatically, which I don't think Elk or SMF will ever do... And if they plan to, just let me say one thing: get yourselves prepared to spend months on this, fixing bugs and adding new features :P)
Quote
since they happen later than the theme's css/javacript.
Ah, yes, that's too bad... ;)
Quote
Just the possibility to use another JavaScript library(like Mootools) is impossible now, since JQuery is already baked into the script.
I don't think you could remove jQuery from Wedge, but it's not something that could be done anyway, given that everything's using it, saving us tons of kilobytes of code. (As a reminder, SMF's script.js is about 50KB, Wedge's is 24KB, and is cached to under 5KB... Add to this the select box code which I chose to embed in script.js, this adds exactly 2 kilobytes of code.)
MooTools is used by over 10 times less websites than jQuery is. It doesn't mean it's any less good -- it simply means that jQuery managed to get traction faster, and people tend to stick to what's used the most, because it means the community is bigger. It's understandable. jQuery thus has the advantage of offering tons of plugins or snippets that can easily be reused by beginner programmers.
Then again, you can still use MooTools but only if there's a way to ensure Moo doesn't use $. It's silly, but since we unconditionally use $ everywhere, you can't just do add_js("\n\tjQuery.noConflict();"), I'm afraid..!

Also, I don't know anything about bloQS. What is it? A new fork? A ViennaBBS rename? A new product not based on SMF? A theme for SMF?
Quote
I guess also that it comes down to my firm belief that themes should be able to decide the visual output from a dataset - not just sending it further unchanged. Its that separation that are a bit blurred in SMF in some places, and now a bit more in Elkarte. Wedge is a different beast lol, and as I remember last time I had SVN acces(I do remember :) ) it had better division into smaller subtemplates, thereby making it easier to change one small thing instead of the whole thing.
Again, one of Wedge's interests is in having many ways to do something when it comes to templating. So many ways, I tend to forget some. (Heck, I even mentioned <we:head> when Pete correctly referred to it as <we:cat>.)
Its main drawback is that as of now, I have zero documentation written for these methods... You'll have to rely on reading my code, mainly in Subs-Cache, Class-CSS and Subs-Template.
Quote
At least make it possible to change for example the order of header tags, use lists instead of tables and so on.
Just try running Wedge in IE 6 or IE 7. You'll notice that they use tables to show the sidebar. While IE 8 and other browsers use a div :)
Quote
EDIT: one of the obstacles is actually the best of the theme engine, namely the layers. A theme won't know about any layers added by mods unless they check the layer index, and even then cannot know what templates are added..or at least target them without physically having them in their own theme folder.
I don't remember if you can check the 'layer' list in Wedge... Technically it's possible, but I may have prevented it. Hmm, just looked into it. Indeed I'm preventing direct access to the skeleton, but I'm allowing users to retrieve the name of the parent layer of a specified block/layer. And, of course, you can retrieve a particular block/layer and make modifications to it... For instance, move it to another parent or before/after another item, add a layer between its parent and it, or below it, rename the block, add a block/layer before or after it, remove the block entirely, remove the parent layer without removing the block itself, etc... It's nearly endless. And again, only documented in Subs-Template. :^^;:
Quote
That is also something I'd like to change, but not sure of the best way yet. Why do I want to do that? lets say i build a responsive theme that shuffle a sidebar around to fit everything nicely..it will be pointless if a mod add a layer that adds two sidebars lol.
If your code is executed after, you can always check for that I guess... But it'd be simpler to just get in touch with the author and try to do something that doesn't break either ;)
Quote
But maybe its better to continue this in another topic, as its abit on the side of the OP's question.
Done.
I know JQuery will be hard to extract from SMF/Elkarte or Wedge, its a choice one makes, for better or worse and I've opted for Mootools since I am not planning to change that much on the javascript bits. A bit oldschool here, in that not everything HAS to be JS dependant. Its still HTML pages in the end..and the less js the less errors. but of course, some things are just possible with js, so its a compromise.

That Elkarte/SMF 2.1 used these functions are more annoying though. But we'll just have to see if its of any consequence to themers when they start making themes. I suspect it won't matter much, which brings me back - what to do when they are going this way -  making my own I guess. :D

bloQS is the rewrite and culmination of ViennaBBS and the extra features in my premium themes, which I have moved to Sources instead of forcing templates to do it. ViennaBBS was also a rewrite, but I removed too much from SMF for it..so much I found it hard to focus further on it(plus i created an anticipation of the "next great thing" which was distracting). So bloQS is a fork, yes, with a a few goals: to use boards as different content types so i don't have to use ablog/gallery/etc script/mod.Its not new ideas of course, but I feel its getting where I want it this time. Its only a private project, so forgive me for mentioning it here while not being "public" anywhere yet. :) Theres some random discussion at http://www.bloqs.net but only xarcell was there, really stating his own wishes - not mine lol - and has since started his own fork...(..)

Anyways, this discussion have made me think more over this layer/template problem mentioned and ways to approach this. While it will never be as exhausting as Wedge, at least it gives me something rewarding to work on. :)
Re: Wedge templating for designers
« Reply #17, on February 2nd, 2013, 11:31 PM »
Quote from Arantor on February 2nd, 2013, 10:23 PM
Here's the thing about threaded mode... by definition you really need a 'reply to this message' button which would cover that, not fudging it through anything else. It's going to get confusing if people press to reply to something and it isn't conjoined on the page (e.g. pressing a button only to have to go back to the bottom to reply)

A popup reply would solve that, even as an overlay of some kind.

This is ultimately why threaded mode causes trouble because of the multitude of UI parts to it.
Quote
My goal is precisely the same: making mods/plugins work together without limiting each other.
Isn't possible.
Quote
My beef with SMF is that mods have always taken precedence, while ideally it should be equal.
Not from SMF's point of view. From the user's point of view, perhaps. They just want it all to work and don't have to care about it. It wasn't until 2.0/2.1 that SMF had anything like features that could support this, and even then SMF doesn't have enough to do it properly, not even in 2.1.
Quote
Mods add features, themes adds design, the two should not interfere..and the theme engine will be the glue between those two.
Missing the point.

Mods add features, they have to remember to use the right markup - i.e. working to the theme. If you look back through everything we've done, mods are actually more constrained than themes are, by design, to account for this sort of problem. And even we haven't nailed it entirely.
Quote
So having mods just go right in and change templates are a bad thing, and course themes not rendering mod's output equally bad.
Which is exactly why they have to work together. Not be separate and glued together. They have to make some compromises, no matter how you might wish otherwise. And bear in mind, this isn't theoretical, most of this stuff works already. As shown on this very site - there are multiple plugins here that integrate just fine.
Quote
What I do want though is that plugins also *just work*..but ultimately the theme makes them look great. Binding the HTML+CSS in such a way that the theme cannot reach them is a then a dead end IMO. But I have no definite answers to how to get there..only ideas to try out.
What you're saying is what you've been saying since this conversation started, that the theme has total control. That's fine, all the time plugins don't want to do anything outlandish or in any way imaginative because then they're screwed because they're bound to what the theme actually lets them do. For it to work in any practical fashion there must be compromise, not total control in one direction or the other.

I wouldn't want to write plugins for your setup because they don't give me any freedom in how I design any of it. In your setup, for example, SimpleDesk would have had to use the same layout as given by anything else, which doesn't work because it had its own requirements in terms of content and presentation. This is why the plugin has to have *some* control over what it's doing.
I did say that plugins would provide the prefered markup, but allowing themes to change that? But yes, I make no illusions about it - I want themes to be all they can be, and I am not so concerned about what mods might like to do. Think of its this way: if themes can change *everything* outputted by core features, why can't it do the same for mods/plugins? Why must plugin authors have more control than core devs in this manner? the obstacle for theme to do that is finding out exactly what IS there in a easy and transparent way, if possible. Core features have a set amount of templates, you can pick and choose what to change for your theme..but in the case of mods/plugins its quite another.

Maybe it isn't possible, but I will try finding that out.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Wedge templating for designers
« Reply #18, on February 2nd, 2013, 11:37 PM »
So, essentially, what you're saying is, that as a theme designer, you want to not only control the look and feel of the core but have the theme able to control the look and feel of plugins too. Have ever so much fun with that. There are hundreds of mods on the sm.org mod site... you are potentially saying you want a theme to have the option of supporting each of them, individually, in potential... because there aren't so many issues with performance, or reliability or tracing bugs that can happen with that or anything.

Let's take a practical example. Would you, as a theme developer consider manually replacing the output of - say - the most popular shoutbox, most popular portal, and most popular gallery?

You have a core theme and you have a theme changing the look and feel. Are you seriously going to want to support things like the portal, gallery and shoutbox in the theme?

Do you remember the themes that had custom code just for TP support and how many issues that caused? This is no different in any practical respect...
Re: Wedge templating for designers
« Reply #19, on February 2nd, 2013, 11:59 PM »
The theme controls the output of the core already..all the templates are there to be replaced if you wish, in SMF. Write a theme that replaces all the templates and yes, you essentially rewrite the output. As I mentioned many times, mods have been a obstacle to that, and hooks are a bit better in this..but in a way you don't know what to expect then, just hope that the mod author have some good sense in writing HTML code that will work with your theme - if its the designers wish to change that as well. If not, well theres no issue of course.

I have tried replacing templates for popular mods, and it didn't work for the obvious reasons: keeping up with mod changes, the sheer number of mods to support and sometimes conflicts between mods.I am not denying that, but I also know and love the power of the theme engine in SMF and THATS my focus.

I see wheres this is going lol, you have your experience and views on it, and they will not be what I envision or can fully agreed on. So not taking it the wrong way since that has happened in the past - but I don't think you can ever see it my way. Which is fine, I am only making my thoughts in writing here, they are not ultimate truths. I am not out to change Wedge since I know you have a firm direction for it(thats a good thing of course) and I hope that will be returned. ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Wedge templating for designers
« Reply #20, on February 3rd, 2013, 12:59 AM »
I can see entirely where you're coming from - I always have been able to. The problem is that your envisioning of it does not tie up to the reality of how it works - even you yourself see that it's impossible for a theme to have total control over mods because of keeping up with mod changes.

There is actually *more* power in Wedge's theme engine than in SMF's, vastly more, and it enables plugins to be more flexible by moving blocks of content around, inserting new blocks of content between them. None of that's changed. And plugins have more ability to play nicely with themes now.

I guess what frustrates me about this topic is that we seem to be retreading the same ground every 6 months and nothing has changed in that time, at least not in the practical world.

Your ideas are grand, but unfortunately I don't see how they can possibly stand up to real world use. That's fine if what you're doing is solely for your own use, when you don't have to care about real world users, but we have to.

Go and look at al the platforms out there, every single forum system has the same problems, and the same problems creep into WordPress too... and I hope you're not going to tell me that WordPress is 'less flexible' than SMF because we both know that's not true either. WP gives theme authors the nearest thing to total control and that causes almost as much of a mess for plugins as what SMF does. More, in some respects, because it can be hard to nail down and make sense of it.

I'm sorry, I have to ask this because it's been bugging me: if you understand we have a firm direction (and one that hasn't changed in over a year, I might add), why keep bringing these things up every few months? You don't want to change our minds, you say, and yet by bringing it up again and again, you're trying to. Or at least, I don't understand why you're bringing it up again and again, when you know it's not going to change.

We did take in to account what you were saying; that's how the template skeleton came into being at all. It was the only way we could think of to find any kind of compromise between the two because we believe the two need to work together - and it's the nearest we've got to that point. I'm sorry that you're so unable to understand that we have to have this compromise between the two but that's the curse of working on something that is intended for widespread distribution, not a hobby project.[1]
 1. I do not wish to be rude, but I don't know how else to classify bloQs or ViennaBBS or whatever it is called, it seems like it is a fine hobby project, which is a great thing in itself, but that has never really been our goal with Wedge if we're honest.
Re: Wedge templating for designers
« Reply #21, on February 3rd, 2013, 09:45 AM »
Stubborness? :)

Look, this is getting where I didn't want it to go. The focus here isn't my stuff, but Wedge. If you feel its working great in these areas I've brought up, then fine, I'll check it out.

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Wedge templating for designers
« Reply #22, on February 3rd, 2013, 03:11 PM »
I feel the templlating engine is very good, more flexible than SMF's. In my plugins, I can insert my block virtually anywhere, above or below any known existing block. No complaints there!

Most importantly, I'm not limited to one sub template.

Also, I have to follow the default theme style and markup. Otherwise, if the theme could do its own thing entirely, I couldn't know if my plugin holds up. Equals support issues. I hate those.

To comment on the "stubbornness" apparently being perceived, there is an element of that, certainly. But it works for everyone here giving a crap about. I have more freedom here than with SMF's theme engine, and for that, I'm thankful.
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.
« This describes me somewhat
Remove flash dependency from AeMe? »