Show Likes

This section allows you to view all posts where this member received or gave a like to.

1
Off-topic / Re: WEDGEHAMMER 40,000
Nao « on April 30th, 2013, 02:43 PM »
I'll give you an example, wanchope... Last night, I decided to try and optimize the CSS suffix system to allow for more flexibility.

Currently, if you want to include some custom CSS for IE6 and IE7 only, you can add this to your skin folder:

custom.ie[-7].css

But if you want to do that, except for yourself (admin), in case for instance you're testing something, you can't do this:

custom.ie[-7] && !admin.css

This syntax is valid inside the CSS file itself, through "@if ie[-7] && !admin / @endif", but not in the suffixes.
I was contemplating the possibility to give up on suffixes, and just force everyone to use @if, but it would be a bad decision, because these suffixes at least allow you to include additional files that you'd have a hard time including otherwise, i.e. if you don't want to put everything into "custom.css", which may quickly become a real mess...

So, I rewrote many things internally. Did many tests. Right now, I'm envisioning changing the current $user_info replacement, which is called "we::$user" (if you're unfamiliar with this syntax, it means "$user static array inside the 'we' system object", and allows you to bypass declaring a global everytime you want to use it, which is nice), and split it into more variables. Right now I have we::$user and we::$browser, but I'm probably going to go for we::$user (for regular user variables), we::$is (for anything related to the user that has 'is_' in it, such as admin or mod testing), we::$browser (no changes except removing the 'is_', tests what browser you're using), and we::$os, which currently is integrated into we::$browser, but really we don't need this to confuse us...

This is a 'convenience' change, which I'm going to do in order to make things simpler for both me and other developers in the future (unless Pete reads this before I commit later tonight, and thinks it's a bad idea.. ;)), and which isn't going to help in any other way than, as I said, clarity. This kind of change, Wedge were to be currently available, would mean that I'd think twice about it, because *plugins may need to be rewritten..!* And yes, this is one of the reasons SMF is always behind Wedge in that respect -- because they have to accomodate for all earlier mods and themes that people have written. When we started Wedge, one of the first liberating things to do was get rid of all the old code that was only there for compatibility reasons, and rewrite it in a more sensible way...

We are not gods, we are good developers and that's all, so we can't everything right on the first try. I know that my caching system, which has great complexity (but that doesn't matter because it's not to be modified by anything else than the ones who wrote it anyway), works perfectly with the current @if and suffix system, just 'differently', and I'd like to rewrite it in a way that'll be (slightly) more maintainable in the future, and account for the merging of both systems. I would really, really think twice before doing it if Wedge was public.
There are other areas that might warrant a similar rewrite, and keeping Wedge private for now entitles us to give it time to develop into a perfect system that we can really, really be proud about, and that won't require breaking rewrites in the near future.

Now, if all you want is to 'prepare' for your forum to be converted to Wedge in the future, just stick with SMF 2.1 for now, as they're doing some great work to catch up with Wedge, and have adopted many of our philosophies and thus your switch might be easier once Wedge is released, if you still want to switch of course...