« Password Hashing
Template skeleton!
Zencart and a forum »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #30, on September 9th, 2011, 01:48 AM »
Quote
I suspect you want mods to do all the work lol..but why? Let the admin+theme do all that.
Two words: WordPress Widgets. That is essentially how they work. And what a mind fuck that is. You end up with themes having to state what widgets they support and vice versa.

There has to be a middle ground, of reasonably rigid definition, that both sides can reasonably expect to be present. Turning it on one side so that one side has all the power, it hamstrings the potential of the other.

SMF put too much power in the modder's hands, what you're suggesting removes most of the power they would actually have. I want a middle ground where I can write code that I have a reasonable expectation of being supported the way I want it to be, not some vague notion of support.

Also, if anything, it's actually making life a lot harder for themers to do anything creative. Because I guarantee you that if themers are given totally free reign, people will have trouble using add-ons because they just won't work as expected. Take a look at WordPress sometime and how many people really do have trouble with Widgets - and how many themes actively state what they support for just that reason: because they give an awful lot of flexibility to the themer and little to the modder in any real sense.

Having some semblance of structure ensures that both sides have a reasonable expectation of things working.
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

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #31, on September 9th, 2011, 07:40 AM »Last edited on September 9th, 2011, 07:54 AM by Nao
How about we assign a left:right:bottom:top var to layer names in skeletons? Only one per direction per skeleton.

<main_wrap:left>

Would mean "if a mod asks to add a subtemplate to the left, use this layer." like a shortcut!

We could have more directions or even other hints, as separated by commas.

And loadSubtemplate('tempy', array('left', 'hello')) would mean add a subtemp to the left-hinted layer, and fallback to the hello layer if not found.
Heck. I can even have a global fallback to the main layer or whatever!

What a smart idea :eheh:

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #32, on September 9th, 2011, 09:18 AM »
Quote
you describe something I don't want either
Ah, see, I was describing what I saw from what you were saying: a setup that is surely a path to hell and back. Joomla, WP, Drupal (to a lesser degree) all have these problems.
Quote
The theme would HAVE to give it back to make it work.
Then the theme doesn't have final control, does it? It has a reasonable contract to fulfill, which is the state of play that we were approaching anyway.
Quote
where some themes support 4 spots, others 25 lol.
That's the scenario I want to avoid and one that your suggestion didn't seem to exclude from happening, if anything it seemed to encourage it, since leaving it up to the theme means that themers are going to do bizarre things like disallow certain areas because their design doesn't support it.
Quote
Would mean "if a mod asks to add a subtemplate to the left, use this layer." like a shortcut!
I like that.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #33, on September 9th, 2011, 01:15 PM »
So, Bjorn, what do you think about the latest changes to Wedge...? The skeleton in general I know you like, but how about the semantic pseudo-elements?

It's only there as a canvas. Ideally, designers should tell me what the list of pseudo-elements would be eventually -- i.e. whatever helps a designer make a semantically solid theme.

Just watched Tucker & Dale vs. Evil... What a fun movie :lol:
Re: Template skeleton!
« Reply #34, on September 9th, 2011, 01:47 PM »
Quote from Arantor on September 9th, 2011, 12:59 AM
Before worrying about implementation, nail down the exact details of how it's supposed to work, where avatars and attachments should be stored (one folder for each, multiple folders?),
Oh, it's already been nailed on for a while... First time an avatar is created, an album is silently created, using /media/avatars/ as its target folder. Same for attachments, with /media/files/. The folders are already in my local copy but I just noticed they're not in SVN...
Anyway-- they'll behave like normal albums, i.e. new sub-folders created after a sub-folder is full. The idea is that whatever the obfuscation setting is, thumbnails will always be visible to everyone, because it'd be stupid to expect a web server to take dozens of extra PHP connections just for these. (Or maybe we could put a dummy avatar if user doesn't have the right to view them... Anyway, this kind of thing is done via Load.php anyway, not through the usual AeMe codepath.)
Other than that... I don't see any biggie.
Quote
how that should be referenced in the code (new album, mythical album 0 or something else?) and stuff like that.
No, it can't be album 0 because we need different albums for avatars and files. It's easier internally to help people choose their avatar from an existing pool. (They can always move their files to the avatar album later if they want to use them as avatars...)
Quote
It's a complex job and it has consequences that are far reaching, so best to look at that first before touching the code, IMO.
I don't think it has that many consequences. The main consequence is that many, MANY functions and settings will have to go, and that's probably the part I'm a bit scared to screw up...
Other than that, I don't think there would be any reason to use different album settings for avatars and files, compared to other albums. It's just... easier to apply the same settings to everything. The only difference being that Wedge will directly retrieve avatars from the media table.

Oh, and I'm also not looking forward to dealing with the Attachment feature in post pages... I mean, I like the 'simplicity' of it, and I'd like to do something between our current popup and the current attachment solution for that.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #35, on September 9th, 2011, 02:03 PM »
Quote
Oh, and I'm also not looking forward to dealing with the Attachment feature in post pages... I mean, I like the 'simplicity' of it, and I'd like to do something between our current popup and the current attachment solution for that.
Hmm, yes, that is an interesting point. The current solution is 'nice', it's straight forward, it's elegant, but it doesn't allow for adding more complex data to the attachment like the popup would.

What about perhaps enhancing that with an async solution, to have the file uploaded there and then, with the option to open the file in the media area for editing?

The stuff around attachments is pretty complex, but not for the obvious reason: it's not that it just uploads stuff and does error handling, but that it has a complicated habit of stashing stuff in session. Specifically that if you upload a file or two while posting but there's an error, the files are preserved in the temporary folder, with the details for them (for renaming/moving to the actual attachments folder) in session.

I spent a surprising amount of time figuring it out for SimpleDesk, because it is pretty complicated to get it right, but that might be a good place to start because it breaks the process down into stages unlike Post2.php which doesn't (and you can see the stuff that I had to write to bridge to SMF's own functions, which I think will help make the logic slightly easier to follow)

Though of course, if the file's sent asynchronously, that stops being a problem anyway.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #36, on September 9th, 2011, 03:17 PM »
Okay, just keep me posted :) I feel like the current implementation is a work in progress, even though it's probably fully functional and 95% done -- but I'm sure there are ways it can be made more helpful to designers. :)
Posted: September 9th, 2011, 03:12 PM

Missed that post...
Quote from Arantor on September 9th, 2011, 02:03 PM
Hmm, yes, that is an interesting point. The current solution is 'nice', it's straight forward, it's elegant, but it doesn't allow for adding more complex data to the attachment like the popup would.
It can be done through Ajax, really... Like, I'm simply selecting the file, then if the File API is supported, it starts uploading it and adds a box somewhere, where I can enter data. Then I also add another file input to upload something else. (Adding it above the rest, so I can upload several files without having to scroll...)
(Heck, the good thing with the file API is that IIRC it also allows for multiple file selection... It needs to be implemented, too.)
Quote
The stuff around attachments is pretty complex, but not for the obvious reason: it's not that it just uploads stuff and does error handling, but that it has a complicated habit of stashing stuff in session. Specifically that if you upload a file or two while posting but there's an error, the files are preserved in the temporary folder, with the details for them (for renaming/moving to the actual attachments folder) in session.
Hmm, didn't know that...
Well, I guess this is the kind of thing that would have to go, unless we implement it into the media area.
Posted: September 9th, 2011, 03:16 PM

(Split and moved to a non-blog area.)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #37, on September 9th, 2011, 03:22 PM »
Quote
Hmm, didn't know that...
Well, I guess this is the kind of thing that would have to go, unless we implement it into the media area.
It's not well known unless you ever had a reason to dabble in the attachments code.

Doing it asynchronously one way or another would definitely remove the need for that code in its entirety (and would simplify WedgeDesk too)

I'd certainly prefer the UI aspect of asynch uploads (AJAX, Flash, whatever)

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #38, on September 9th, 2011, 03:47 PM »
I'm just not sure about this for now -- I want it to be done, but I'm a bit rusty when it comes to managing uploads... Been a couple of years since I last jumped into media code!
Re: Template skeleton!
« Reply #40, on September 12th, 2011, 03:20 PM »
Okay, I'll still need opinions on something...

This is from the default skeleton:

Code: [Select]
<wrapper>
<header />
<menu />
<linktree />
<content_wrap>
<sidebar_wrap>
<sidebar:side></sidebar>
</sidebar_wrap>
<offside_wrap>
<main_wrap>
<top:top></top>
<main:main>
<main />
</main>
</main_wrap>
</offside_wrap>
</content_wrap>
<footer />
</wrapper>

Alternatively, I've added header_wrap and footer_wrap layers:

Code: [Select]
<wrapper>
<header_wrap>
<header />
<menu />
<linktree />
</header_wrap>
<content_wrap>
<sidebar_wrap>
<sidebar:side></sidebar>
</sidebar_wrap>
<offside_wrap>
<main_wrap>
<top:top></top>
<main:main>
<main />
</main>
</main_wrap>
</offside_wrap>
</content_wrap>
<footer_wrap>
<footer />
</footer_wrap>
</wrapper>

These layers are unused, but the second version ensures that no single layer holds a combination of layers and blocks. Meaning that a layer can only hold either one or more layers, or one or more blocks.

The code that is currently in SVN allows for layers to have both layers and blocks. The good point is that it gives flexibility to themers. The bad point is that once you start mixing these together, it might lead into unexpected results -- which I can control through code, but I'm wondering whether it's best to leave freedom to themers, or force them to put blocks away from layers. However, the solution of putting everything into layers may not be better actually.

Right now I'm only seeing ONE potential problem with layer/block mixes, and it is when using the default setting for loadBlock, i.e. replace existing blocks in a layer with the new one.
- In the second version, it'll be all good, because all I'll be doing is replace the contents of the parent layer. BUT... If a layer is found within the parent layer though, what do I do? Create a new layer and insert the block in it? What name do I give it?
- In the first version though, if I want to insert a block in <content_wrap>, what do I do? Do I remove all of the existing child layers and child blocks? Do I delete only the child blocks? If yes, should I insert the block in place of the first one (which will be removed), or after the last layer? -- Of course, it's likely that if someone tries to replace blocks in such a non-trivial layer, they made a mistake. However, if I just want to add a block to <content_wrap>, it's easy enough, I don't have to create a dummy layer for it.

What do you think would be best, then...?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #41, on September 12th, 2011, 03:29 PM »
Quote
The code that is currently in SVN allows for layers to have both layers and blocks.
Surely, the contents of main_wrap has both a block and a layer in it?[1]

I honestly wouldn't make replace the default; if someone does want to replace the entire contents of a layer, fine, but don't make that the default state of play. (And if they do want to replace, discard the entire contents of that layer and be done with it)

Instead, I'd suggest append should be the default of the day, if someone adds to a layer, the typical behaviour is going to be to add it to the end of the layer. If they can add it arbitrarily inside the layer (before all, before/after a given node) that's important, but at the end should be the default.

If in doubt, think about the typical DOM methods exposed in jQuery as the sorts of operations people do actually want to do: replaceWith, before, after, prepend, append, and wrap. The same operations would typically be desirable for managing blocks and layers - which really aren't any different to DOM manipulation.[2]
 1. Assuming I haven't muddled the terminology up.
 2. It is more than just a passing similarity, since the skeleton's pseudo-XML is representational of the content's own HTML anyway.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #42, on September 12th, 2011, 03:43 PM »
BTW, last commit has a tiny issue in that it inverts the boolean values for $where, which won't matter since I planned to rewrite that anyway (done.)
Quote from Arantor on September 12th, 2011, 03:29 PM
Quote
The code that is currently in SVN allows for layers to have both layers and blocks.
Surely, the contents of main_wrap has both a block and a layer in it?[1]
 1. Assuming I haven't muddled the terminology up.
Nope... main_wrap has two layers in it. The 'top' layer is empty by default. <top></top> defines an empty layer, while <top /> defines a block.
Maybe I should reconsider the way I'm doing it, though...? Maybe not use pseudo-HTML, but something else? Or use a <layer:mylayer:side,left> and <block:myblock> instead of <layer> and <block />?
Quote
I honestly wouldn't make replace the default;
Because of the main layer, yes it should be :)
loadBlock() is called over 300 times in the entire codebase. loadBlock with a $where parameter (i.e. "don't replace, do something else") is called less than 20 times...
I could limit loadBlock() to the main layer though, and have addBlock() and removeBlock() functions that are for other situations. (But then I'd probably have to change loadLayer(), too... ;))
Quote
if someone does want to replace the entire contents of a layer, fine, but don't make that the default state of play. (And if they do want to replace, discard the entire contents of that layer and be done with it)
What if they 'simply' want to discard the blocks in the layer and keep the child layers?
Hmm... Yeah, I can already hear you say, "who would do that anyway" ;)
Quote
Instead, I'd suggest append should be the default of the day, if someone adds to a layer, the typical behaviour is going to be to add it to the end of the layer.
But doing that in the main layer will break it. For instance, if you go to the Change Skin page, and disable the replacement of blocks, loadBlock() will add the 'pick' block to the lot, so it will call both 'main' and 'pick', which in turns will generate errors because it'll start to show the Admin Theme area... ;)
Quote
If in doubt, think about the typical DOM methods exposed in jQuery as the sorts of operations people do actually want to do: replaceWith, before, after, prepend, append, and wrap.
Yeah, jQuery probably got it right... ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #43, on September 12th, 2011, 03:53 PM »
Ah, I got the terminology slightly off then.

Regarding replace vs append, there's one fairly good reason why I'd suggest it should be append: mods.

Sure, themers and the core code will typically do replace, because they don't have to care about the consequences nearly as much - they're setting the canvas that mods will later work with.

WedgeDesk used the old subtemplate insertion code, to add subtemplates and so on e.g. to the sidebar, and not once did it do a replace, it was always doing appends.

That said, if the core code does 300 vs 20, then it should probably stand and modders will just have to use it the way I've used it thus far :lol:
Quote
What if they 'simply' want to discard the blocks in the layer and keep the child layers?
Hmm... Yeah, I can already hear you say, "who would do that anyway"
I can think of reasons why you might.
Quote
But doing that in the main layer will break it. For instance, if you go to the Change Skin page, and disable the replacement of blocks, loadBlock() will add the 'pick' block to the lot, so it will call both 'main' and 'pick', which in turns will generate errors because it'll start to show the Admin Theme area...
Argh, yes, I can see the problem.
Quote
Yeah, jQuery probably got it right...
Well, remember that unlike the DOM specification, jQuery was built by and for people who actually *use* the DOM. So the spec says that insertBefore, insert-as-last and removeChild are enough, but the real world needs to use replace, before, after, etc. (And yes, there should have been a remove operation on that list)

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #44, on September 12th, 2011, 07:15 PM »
Quote from Arantor on September 12th, 2011, 03:53 PM
Regarding replace vs append, there's one fairly good reason why I'd suggest it should be append: mods.
I know, I know...
What I could do: loadBlock will do a replace when called on ':main', and an add when called on anything else. Would that be reasonable, or would it confuse users?
If we end up changing all of Wedge's loadBlock calls to specify 'replace', modders may also be confused, I don't know... I mean, I think most of the loadBlock() calls, even from within mods, will be made on ':main'...
Quote
That said, if the core code does 300 vs 20, then it should probably stand and modders will just have to use it the way I've used it thus far :lol:
Just as I did...
Ah well.
Quote
Quote
What if they 'simply' want to discard the blocks in the layer and keep the child layers?
Hmm... Yeah, I can already hear you say, "who would do that anyway"
I can think of reasons why you might.
Then it gets complicated, eh.

Of course, mods could still potentially modify $context['template_layers'] directly by themselves. It's not like the array is locked once we get out of loadBlock and loadLayer...

Oh my, I realize I'm getting confused by my own implementation. Not by the basics of it, but by whether or not I should allow mixing layers and blocks together, etc... :-/
I don't even remember my original question :lol:
« Password Hashing
Zencart and a forum »