Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
7486
Features / Re: Template skeleton!
« on October 10th, 2011, 01:42 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.
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...?
7487
The Pub / [Archive] Re: Logo Madness
« on October 10th, 2011, 01:28 PM »
Beaks can be cool... As I said: Phantom of the Paradise.
7488
Features / Re: Template skeleton!
« 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]
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?
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:
// 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?
7489
Features / Re: Template skeleton!
« 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 :)
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 :)
7490
Features / Re: Template skeleton!
« on October 10th, 2011, 10:39 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 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.
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+"...)
7491
Features / Re: Template skeleton!
« on October 10th, 2011, 10:08 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.
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.)
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.
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?
7492
Features / Re: Template skeleton!
« on October 10th, 2011, 09:19 AM »Ah, so it was me misinterpreting, my bad.
I always thought of layers as being essentially blocks that contain other blocks; there's no real special layer-only behaviour that doesn't logically also apply to blocks, with the exception of being a parent. So yeah, a single fused function would be pretty neat.
Somehow, then, it makes sense to declare them as an array in wetem::load() because it shows anyone reading the code that this is a container for blocks.
I'd also suggest that it is done using flipping and is done that way to allow for sanitisation, though that's just my gut instinct, there's no real reason to insist on it (much as there wasn't much need to sanitise what went into the old template_layers setup)
Oh my, if only I could do it myself... I mean, put the template code into an object...
Heck, I'll just look at the other objects and give it a try. The skeleton is so dying to be an object...
PS: the use of wetem::load would also imply we couldn't load a layer by just specifying a string, it would have to be array('layer' => array()), but we could either add aliases to that, or simply rely on the fact that no one ever adds a layer without also specifying at least a sub-block at the same time...
7493
Features / Re: Template skeleton!
« on October 10th, 2011, 09:09 AM »
It's not a bug, actually... It's as designed. loadLayer() is not supposed to be able to add layers relative to blocks, only to layers.
However, I'm aware that loadBlock() can do it for both blocks and layers, so it only makes sense to allow the same level of creativity for loadLayer(), so I'll look into it.
I'm also looking into, maybe fusing both functions into a 'load' function (wetem::load?) that will take care of inserting a block, layer or array of blocks and layers into a specific position.
I think it'd probably make sense to have something like this...
wetem::load(
array(
'layer' => array(),
'layer2' => array(
'block',
),
'block2',
),
'default',
'add'
);
What do you think...?
The only 'issue' is that I'll have to analyze the array to create a new 'proper' array that looks like what's actually in use in the skeleton array:
array(
'layer' => array(),
'layer2' => array(
'block' => 1,
),
'block2' => 1,
)
i.e. flip block items (and these only), but recursively... (Added benefit: can possibly add some kind of sanitization later on.)
Or I could change the skeleton code to actually do it the other way around, hence removing the need to flip anything... (But no sanitization, of course.)
What do you think?
PS: the use of wetem::load would also imply we couldn't load a layer by just specifying a string, it would have to be array('layer' => array()), but we could either add aliases to that, or simply rely on the fact that no one ever adds a layer without also specifying at least a sub-block at the same time...
However, I'm aware that loadBlock() can do it for both blocks and layers, so it only makes sense to allow the same level of creativity for loadLayer(), so I'll look into it.
I'm also looking into, maybe fusing both functions into a 'load' function (wetem::load?) that will take care of inserting a block, layer or array of blocks and layers into a specific position.
I think it'd probably make sense to have something like this...
wetem::load(
array(
'layer' => array(),
'layer2' => array(
'block',
),
'block2',
),
'default',
'add'
);
What do you think...?
The only 'issue' is that I'll have to analyze the array to create a new 'proper' array that looks like what's actually in use in the skeleton array:
array(
'layer' => array(),
'layer2' => array(
'block' => 1,
),
'block2' => 1,
)
i.e. flip block items (and these only), but recursively... (Added benefit: can possibly add some kind of sanitization later on.)
Or I could change the skeleton code to actually do it the other way around, hence removing the need to flip anything... (But no sanitization, of course.)
What do you think?
Posted: October 10th, 2011, 09:07 AM
PS: the use of wetem::load would also imply we couldn't load a layer by just specifying a string, it would have to be array('layer' => array()), but we could either add aliases to that, or simply rely on the fact that no one ever adds a layer without also specifying at least a sub-block at the same time...
7494
The Pub / Re: Spell checker
« on October 10th, 2011, 08:20 AM »
Works well with French I reckon.
Still surprised you're so active when you're alone on that project. How do you do that. No moral support!
You should be working on Wedge at some point. If you can adapt to the smf coding guidelines it'd be a perfect fit. More exposure for your code. Especially given how you've been progressively dropping smf compatibility (don't tell me your new hooks are interoperable with smf. ;))
I saw you removed the backup system too this weekend, just as Pete did ;) really, isnt it annoying for you to reinvent the wheel, knowing that in addition you'll have to support your fork by yourself?
Still surprised you're so active when you're alone on that project. How do you do that. No moral support!
You should be working on Wedge at some point. If you can adapt to the smf coding guidelines it'd be a perfect fit. More exposure for your code. Especially given how you've been progressively dropping smf compatibility (don't tell me your new hooks are interoperable with smf. ;))
I saw you removed the backup system too this weekend, just as Pete did ;) really, isnt it annoying for you to reinvent the wheel, knowing that in addition you'll have to support your fork by yourself?
7495
Development blog / Re: Anniwersary
« on October 10th, 2011, 07:41 AM »
Hey we're closing in on 14 months now :P
7496
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 9th, 2011, 11:17 PM »
You dd a fantastic job this week. For the first time in months (ever?), you beat me in number of commits, and by far, without me even slowing down my usual pace. I'm also very thankful that you decided to tackle some of my todo list. Ive always known you're a great coder and felt a bit lonely these last few months. It's really good to know I can slow down if I want (because of my very severe burnout) and wedge will still be worked on. Again thanks :)
7497
The Pub / [Archive] Re: Logo Madness
« on October 9th, 2011, 11:03 PM »
I'm not expecting anyone to do it -- just offering to all the ability to customize the logo to their liking and then suggest their version. If they want :)
Oh, while I'm at it... A message to those who can access the SVN. Do you remember Wedge's menu looking like THIS...?
Please note the huge vertical padding between the menu and the lower line representing the end of the menu area.
I don't remember ever seeing this -- but my current index.css is a bit modified and I don't want to revert my copy to test that.
So, to be clear: this will be fixed in the next commit... I'm just surprised this is happening to me in the demo site.
Quote from Nao on October 9th, 2011, 10:16 PM Looks like I'm getting this in Chrome and Opera 12, but not in Opera 11.51... (??)
Need confirmations!
Oh, while I'm at it... A message to those who can access the SVN. Do you remember Wedge's menu looking like THIS...?
Please note the huge vertical padding between the menu and the lower line representing the end of the menu area.
I don't remember ever seeing this -- but my current index.css is a bit modified and I don't want to revert my copy to test that.
So, to be clear: this will be fixed in the next commit... I'm just surprised this is happening to me in the demo site.
Posted: October 9th, 2011, 10:16 PM
Oh, while I'm at it... A message to those who can access the SVN. Do you remember Wedge's menu looking like THIS...?
Need confirmations!
7498
Features / Re: New revs
« on October 9th, 2011, 10:58 PM »
rev 1079
(6 files, 10kb)
* Fixed/improved/tweaked main menu padding and notice handling in all browsers. (index.css, index.ie*.css)
* Not exactly sure why I used array_fill(0, count($blocks), true) instead of just $blocks... We don't care about the values in it, just about the number of items it has. (Subs-Template.php)
(6 files, 10kb)
* Fixed/improved/tweaked main menu padding and notice handling in all browsers. (index.css, index.ie*.css)
* Not exactly sure why I used array_fill(0, count($blocks), true) instead of just $blocks... We don't care about the values in it, just about the number of items it has. (Subs-Template.php)
7499
The Pub / [Archive] Re: Logo Madness
« on October 9th, 2011, 07:48 PM »
Added a solution halfway between the others... Not super-convinced.
I like them all, though, but I like the 'square' logo, too. I'm just trying to find something that convinces me by being both organic (natural, chaotic) and ordered (straightened, professional).
Hmm... Might as well attach some of my latest .ai files. If any of you Illustrator addicts want to give it a try... You'll see how I created the latest logos -- by tweaking an 'Arc' effect, ah ah. Well, it still required some work.
I like them all, though, but I like the 'square' logo, too. I'm just trying to find something that convinces me by being both organic (natural, chaotic) and ordered (straightened, professional).
Hmm... Might as well attach some of my latest .ai files. If any of you Illustrator addicts want to give it a try... You'll see how I created the latest logos -- by tweaking an 'Arc' effect, ah ah. Well, it still required some work.
7500
Features / Re: Scheduled tasks interface
« on October 9th, 2011, 06:27 PM »
You can always write a ui for wedge 2 if you're bored Eheh.