Wedge

Nao · « Reply #75, on October 10th, 2011, 10:08 AM »

Quote from Arantor on October 10th, 2011, 09:31 AM

I actually thought the same to start with, and somewhere I managed to forget that, probably around the time I realised that from a plugin author's POV, there's no difference, and that a layer is semantically a block that can contain other blocks.

Yeah...
Actually, we could even get rid of '_before' and '_after' and use '_above' and '_below' instead for block overrides, considering that they're just like a layer, too... (Only layers don't have a central function to call.)
Or the other way around-- rename _above and _below to _before and _after.
What's nice with our layers is that they don't even require _above and _below, meaning layers can just be used as a way to put a bit more structure to the skeleton, e.g. make it easy to add a block at the end of a thematic series of blocks, without having to know the names of the blocks (e.g. if they're added conditionally.)

Quote

Look at wesql, it's really similar structurally in this case. There's private variables (much like the template skeleton itself should be as only wetem needs to deal with it), the setup stuff and then public functions.

Yeah, I'm looking into it... Working on it.
I'm a bit rusty (or the other way around -- a virgin) when it comes to object building. I did build wecss but it was based upon another object, and I did have trouble with it. Someone remind me -- when should I use self::function and when should I use wetem::function, inside the wetem object? Is any of the two faster, or is it just about scope (i.e. if I use one it'll crash, if I use the other it'll work)?
Are there any noticeable performance penalties in calling these functions? e.g. a recursive function... If I called it a hundred times, would it make sense to optimize the way it's called?

Arantor · « Reply #76, on October 10th, 2011, 10:15 AM »

Quote

Actually, we could even get rid of '_before' and '_after' and use '_above' and '_below' instead for block overrides, considering that they're just like a layer, too... (Only layers don't have a central function to call.)
Or the other way around-- rename _above and _below to _before and _after.

I'm thinking before and after would be nicer, generally. It's more descriptive of what's going on (though above and below is too, just it seems more accurate to say before/after)

Quote

Someone remind me -- when should I use self::function and when should I use wetem::function, inside the wetem object? Is any of the two faster, or is it just about scope (i.e. if I use one it'll crash, if I use the other it'll work)?

I seem to recall a speed difference when I set up wesql, which is IIRC partly why I ended up making them all static functions even though they don't need to be - I seem to remember that if it's non static but still called through wetem:: it'll have to call the setup function in order to have the instance returned. I would imagine self:: would avoid the same overhead.

If it's in a loop, it's always best to test which is fastest, but I don't recall anything huge involved.

Nao · « Reply #77, on October 10th, 2011, 10:39 AM »

Quote from Arantor on October 10th, 2011, 10:15 AM

I'm thinking before and after would be nicer, generally. It's more descriptive of what's going on (though above and below is too, just it seems more accurate to say before/after)

I think it's more accurate too -- probably because _above and _below imply spatial positioning, when these functions could possibly not output anything, or even _above could output a floated div that shows up below the layer, things like that...

Quote

I seem to recall a speed difference when I set up wesql, which is IIRC partly why I ended up making them all static functions even though they don't need to be - I seem to remember that if it's non static but still called through wetem:: it'll have to call the setup function in order to have the instance returned. I would imagine self:: would avoid the same overhead.

All of the functions are static right now.
Okay, I'll just go ahead and finish a working version, and then I'll commit, and I'll let you 'fix' whatever doesn't work...

Hell, I love being finally able to remove the skeleton_ namespace from all functions... :P
What I don't like as much, though, is replacing $context['layers'] with self::$layers. It's shorter, but Notepad2 shows it in plain black and dark blue, instead of 'layers' being shown in limegreen (because it's a string), so it suddenly becomes harder to spot any layer manipulation in the code... Meh. (And before you ask -- one of Notepad2's issues is that it doesn't allow to add a custom color for a regex-delimited string like "self::\$\w+"...)

Arantor · « Reply #78, on October 10th, 2011, 10:45 AM »

Quote

What I don't like as much, though, is replacing $context['layers'] with self::$layers

But the only layers manipulation using wetem::$layers should be inside wetem (and it should be a private variable for this reason) - all the other stuff should be wetem:: calls outside it... though I guess the main places it's used are in Subs-Template currently...

Nope, haven't got a good answer for that one, sorry.

Nao · « Reply #79, on October 10th, 2011, 10:58 AM »

It's not a biggie anyway...
Okay, took me less than an hour to make the transition. Tested on Display.php, after a couple of minutes of debugging it worked flawlessly. :)
self:: can be used anywhere inside the class, I didn't have to rely on wetem::, the only bugs I had were with my build() rewrite where I was trying to avoid using adding a secondary (private) function for it, in the end I did that and it did the skeleton parsing correctly.

Working on converting all loadBlocks and then I'll commit...

PS: and yes, self::$layers is private, of course. That's the whole point of the object :)

Arantor · « Reply #80, on October 10th, 2011, 11:02 AM »

If it works properly, it's probably correctly written ;)

Nao · « Reply #81, on October 10th, 2011, 01:22 PM »

Was busy IRL.
I'm working on converting the templates.
Interestingly, I never noticed but the media codepath (the one that returns an image, similar to dlattach) goes through the entire process and loads even the menu code...
I reckon it should be skipped. Load.php has a $simpleActions array that holds items that don't need a template, but maybe I should instead use the same path as action=dlattach, i.e. skip the code when dlattach skips it. Ultimately I'd like to get rid of most media path calls though, but for now I think it's necessary to lighten it.

Now, I was looking at the index.php file and found this. It's used in a similar fashion in Wedge but here's the SMF code:

Code: [Select]

	// Attachments don't require the entire theme to be loaded.
	if (isset($_REQUEST['action']) && $_REQUEST['action'] == 'dlattach' && (!empty($modSettings['allow_guestAccess']) && $user_info['is_guest']))
		detectBrowser();
	// Load the current theme.  (note that ?theme=1 will also work, may be used for guest theming.)
	else
		loadTheme();

Now... It basically says, "skip loading the theme for dlattach, ONLY if the user is a guest and guest access is enabled.
What's with the guest thing? dlattach will never use theme data AFAIK, so it would make sense to skip loadTheme for everything... What do you think of this?

Arantor · « Reply #82, on October 10th, 2011, 01:28 PM »

I think it's to do with falling back in the event of error. If guest access is off, the theme will be needed. If it's a guest, there's a possibility it'll need the guest to log in (remember: access to attachments is not provided to guests by default)

I'm not sure why else you'd need that, though.

Yes, media should be lightened, which is why I was in favour of pushing serving items into something like dlattach - there's really no need to invoke the entire media action (and all the theme loading) just for serving files.

Nao · « Reply #83, on October 10th, 2011, 01:42 PM »

Quote from Arantor on October 10th, 2011, 01:28 PM

I think it's to do with falling back in the event of error. If guest access is off, the theme will be needed.

Technically, since the item will be called half the time through an img tag, whether you have the theme or not is irrelevant here, since all you'll get is a broken image... As for downloads, Wedge can simply return a "file not found" error or something, without any theme around it. Just plain text...

Quote

If it's a guest, there's a possibility it'll need the guest to log in (remember: access to attachments is not provided to guests by default)

The code as I posted/spotted above will precisely not load the theme code for guests.. (?)

Quote

I'm not sure why else you'd need that, though.

It's quite obscure to me.

Quote

Yes, media should be lightened, which is why I was in favour of pushing serving items into something like dlattach - there's really no need to invoke the entire media action (and all the theme loading) just for serving files.

I'll leave it at that for now...

Okay, I'm starting manually converting the stuff but I suspect I'll do a commit that will break Wedge. Just for sanity reasons -- first committing the main code change, and then committing the fixes to make the whole thing work.

In the meantime, I was thinking, maybe we shouldn't call the block loading code 'load' but use 'add' instead... Because that's precisely what it does. Except for the default layer, I know... :lol:
Well, I suppose (?) I could introduce a few shortcuts, like wetem::add(..., '') would actually call wetem::load(..., '', 'add'). Does that make any sense...?

Arantor · « Reply #84, on October 10th, 2011, 01:45 PM »

Quote

Technically, since the item will be called half the time through an img tag, whether you have the theme or not is irrelevant here, since all you'll get is a broken image... As for downloads, Wedge can simply return a "file not found" error or something, without any theme around it. Just plain text...

True enough!

Quote

The code as I posted/spotted above will precisely not load the theme code for guests.. (?)

Oh, my bad. I was just trying to go through the circumstances in which you might want to but there aren't really any.

Quote

Okay, I'm starting manually converting the stuff but I suspect I'll do a commit that will break Wedge. Just for sanity reasons -- first committing the main code change, and then committing the fixes to make the whole thing work.

Works for me. I'm not in the middle of anything that will be broken if I sync, so I can readily wait until you're done before updating.

Quote

In the meantime, I was thinking, maybe we shouldn't call the block loading code 'load' but use 'add' instead... Because that's precisely what it does. Except for the default layer, I know...

Well, technically it is still adding, even if there wasn't anything to add to before. It's essentially the same as saying x += y but dealing with the case of empty(x) first... no?

To me, calling it 'add' would make more sense.

Nao · « Reply #85, on October 10th, 2011, 02:58 PM »

Quote from Arantor on October 10th, 2011, 01:45 PM

Oh, my bad. I was just trying to go through the circumstances in which you might want to but there aren't really any.

So, you agree we should be doing even less work for dlattach at this point...?

Quote

Works for me. I'm not in the middle of anything that will be broken if I sync, so I can readily wait until you're done before updating.

Well turns out I didn't leave it broken for long (a few minutes). I just split the stuff so I didn't have to mix 'proper changes' with 'site-wide search & replace changes' in the same commit. That way, you can check out my changes while skipping a specific commit so you don't have to go through a long list of boring changes...

I'll do the same if/when I rename the load() method.

Oh, BTW, I've found out why I find it a bit ugly...

loadLanguage()
loadTemplate()
loadBlock()

We have a lot of these together. Now it's like:

loadLanguage()
loadTemplate()
wetem::load()

Meh... It's like I broke the pattern :P

Quote

Quote
In the meantime, I was thinking, maybe we shouldn't call the block loading code 'load' but use 'add' instead... Because that's precisely what it does. Except for the default layer, I know...
Well, technically it is still adding, even if there wasn't anything to add to before. It's essentially the same as saying x += y but dealing with the case of empty(x) first... no?

Hmm no...
I'll think about all of that when I have a moment to resume my work.
In the meantime, feel free to look at my object code and improve it (i.e. anything related to object optimization, not template manipulation, which I'll deal with later to merge the block and layer loading code.)

Quote

To me, calling it 'add' would make more sense.

It definitely makes more sense. Except for the default layer but shhh ;)

Arantor · « Reply #86, on October 10th, 2011, 03:02 PM »

Quote

So, you agree we should be doing even less work for dlattach at this point...?

However you slice it, for something whose purpose is solely to authenticate the user, then serve a file, we should be doing absolutely as little as possible.

If SSI were slimmer I'd suggest dropping dlattach and using an external file instead. Thing is, SSI sets up a whole bunch of stuff like loadTheme calls :/

Quote

Meh... It's like I broke the pattern

I have been wondering about a System class that handles stuff like loading sources and templates, which would give:
wesys::loadTemplate()
wesys::loadSource()

but it's too long, need to shorten it down! :P

Quote

In the meantime, feel free to look at my object code and improve it (i.e. anything related to object optimization, not template manipulation, which I'll deal with later to merge the block and layer loading code.)

I will when I've had my fun with SVG images. I've never done SVG before, it's quite interesting to just play with.

Quote

It definitely makes more sense. Except for the default layer but shhh

How is it different? You're still adding to a list, except the list was totally empty beforehand.

Nao · « Reply #87, on October 10th, 2011, 05:19 PM »

Quote from Arantor on October 10th, 2011, 03:02 PM

However you slice it, for something whose purpose is solely to authenticate the user, then serve a file, we should be doing absolutely as little as possible.

So... Who adds it to their to-do? :P

Quote

I have been wondering about a System class that handles stuff like loading sources and templates, which would give:
wesys::loadTemplate()
wesys::loadSource()

wesys is still a cool name... ;)
It's better than 'wetem', but it doesn't indicate what it's for.

I'm wondering whether execBlock() should be in wetem.
I tried moving it to a private method, but then I remembered that Load.php and other files will use it to run specific functions from template files, such as template_init(), so I made it public, but then it doesn't have much of a point being in the object... Except for being called through self::exec in the render method.
I try having as little data as possible in the object that is not directly related to outputting non-template data. I've been wondering about while_we_re_here(), for example...[1]

I've already sorted out the functions to push everything public to the beginning of the object, and everything private to the end. Seems cleaner to me that way, although on the other hand it also separates some functions from their twins, like render() is no longer followed by render_recursive(). I don't think it's that big a problem, as I'm not going to keep developing wetem forever... After a while, it'll be solid enough that no one will even bother to look at the code.

Oh, and I also turned the static variables into private, and the wetem class to final. I don't see any reason to inherit it... Might as well protect it entirely. If in the future a use is found in inheriting from wetem, then we can always remove the final keyword.

Quote

How is it different? You're still adding to a list, except the list was totally empty beforehand.

But in the case of default, the list is never empty, is it..? It has the 'main' block by default in it...

1.	For the curious, I name that function while listening to a certain Pink Floyd album... :P

Arantor · « Reply #88, on October 10th, 2011, 05:32 PM »

Quote

So... Who adds it to their to-do?

Well, refitting the API is on my todo list for the murky future... but for now, neither of us. There are bigger fish to fry - though it's certainly relevant in the integration of Aeva for attachments.

Quote

I tried moving it to a private method, but then I remembered that Load.php and other files will use it to run specific functions from template files, such as template_init(), so I made it public, but then it doesn't have much of a point being in the object... Except for being called through self::exec in the render method.

Except for the small detail that if it's not part of the object, it won't have access to the object's variables. Does it need access to the block list for any reason, for example?

Quote

I try having as little data as possible in the object that is not directly related to outputting non-template data. I've been wondering about while_we_re_here(), for example...

That's the general idea; stuff that the object doesn't *need*, it shouldn't *have*.

Quote

But in the case of default, the list is never empty, is it..? It has the 'main' block by default in it...

But you're still adding to it, right?

Perhaps a better verb would be 'merge', which covers both adding and replacing...

Nao · « Reply #89, on October 10th, 2011, 05:47 PM »

Quote from Arantor on October 10th, 2011, 05:32 PM

Quote
So... Who adds it to their to-do?
Well, refitting the API is on my todo list for the murky future... but for now, neither of us. There are bigger fish to fry - though it's certainly relevant in the integration of Aeva for attachments.

I'm still so wary of Aeva's bundling...
I mean, today I was thinking again about the comment system for AeMe and wondering whether we should beef it up, make it smaller (in UI at least), or simply integrate it into wedge_messages... Then I was wondering, is it necessary to implement floating topics before we can use wedge_messages to store posts that don't belong in a topic...? And then I thought, do we really need to put all 'floating topics' (i.e. topics, profile comments, media comments...) inside the topic table? Can't we just deal with these in the messages table, have a special 'wedge' field in wedge_messages that allows us to store a message origin, whether a topic, profile or media, I don't know, when I start thinking like that, I start to lose myself in thought...

Last week I was spending an afternoon with a friend who needed my help to configure .htaccess and .htpasswd features on her portfolio website. We spent about 3 hours on it, and in the end she commented to Milady, "I don't know how he does it. With all the music, and with his focus switching from one thing to another every other second..."
But, well, I did it :P And yes I'm probably a bit ADD.

Which brings me back to, ah, these annoying floating topics... I think I should just rename this to 'floating messages' and give up on the idea of storing the type in the topic table, and rather have it in the message table, with a proper index.
(I give you 5 minutes before you tell me it's the worst idea I had this week :P)

Quote

Except for the small detail that if it's not part of the object, it won't have access to the object's variables. Does it need access to the block list for any reason, for example?

Nope, it doesn't... Which is why I didn't push it into the object to begin with. It already has the block's name at this point, so it simply needs to call template_blockname().

Quote

Quote
But in the case of default, the list is never empty, is it..? It has the 'main' block by default in it...
But you're still adding to it, right?

Nope... load('block', 'default') will replace the 'main' block. load('block', 'sidebar') will add to the current blocks.
I think we already went through that... :P

Wedge

Home

Login

Register

Nao

Re: Template skeleton!

Arantor

Re: Template skeleton!

Nao

Re: Template skeleton!

Arantor

Re: Template skeleton!

Nao

Re: Template skeleton!

Arantor

Re: Template skeleton!

Nao

Re: Template skeleton!

Arantor

Re: Template skeleton!

Nao

Re: Template skeleton!

Arantor

Re: Template skeleton!

Nao

Re: Template skeleton!

Arantor

Re: Template skeleton!

Nao

Re: Template skeleton!

Arantor

Re: Template skeleton!

Nao

Re: Template skeleton!