SMF's integration hooks were mostly useless up until 2.0 RC4 wherein they were upgraded to support multiple functions being called at the same point in the execution.
We're keeping most of the existing hooks and adding a lot more of them generally, and combined with SMF's general structure of keeping the current running state in $context (while we'd like to phase that out, doing so is less than trivial),
So yeah, we're not getting rid of them, we're jugging a few around and adding plenty more.
For instance, create a global local array (if I may say), something like $local_array, which we'd global everytime we write a function that offers hooks.
Aaaaand, once again, I'm totally obscure and probably offering to do something that would complicate everything needlessly.
Yeah, $context could be a place to store most of these vars. We could also delete the vars after they become useless, but I don't know, maybe it'd be a waste of time.
Also, rename $context to $cx or something, to make it faster to type?
And we should/would/will try to be open about hook addition requests. Like, "if you add a hook here, I could do this or that without modding the code". If it seems like something that would benefit more mods, then it'll definitely warrant a mod.
Seriously, I think there are many places that should never have been moddable in the first place -- like, adding menu entries. It should be done exclusively via hooks. We just need to educate modders about it.
PS: maybe this conversation should be split into the private area.
Also, rename $context to $cx or something, to make it faster to type?
I'd recommend against it and leave it as a full word so as to be less confusing.Quote from Nao/Gilles on November 11th, 2010, 09:42 PM Also, rename $context to $cx or something, to make it faster to type?
SMC = Simple Machines Core, for things that wouldn't necessarily be strictly forum based but usable in other SM apps; it was in the mists of time actually $smfFunc.
There are other things we can do at this point, more on that elsewhere.
It's an interesting idea but not entirely practical,
mostly because there's already $context, and partly because hooks are there for a specific purpose, not just a convenient place in time; the actions hook for example is there specifically to be used with modifying the list of actions.
Really, pushing things to a 'global local' function is bad juju because really one thing I want to do is empty some stuff out of $context rather than fill it up more.
Faster, yes, more likely to collide with new local (temporary) variables but no real issue either way.
Sure :) Though a fair amount will be anticipation as well,
I have a litany of mods in mind that I'm constantly thinking... "how can I make that work without editing the code?" That's really my baseline when I'm thinking of the changes to make.
I'm actually fine with it here, because
I want to not only explain why things won't work but also the rationale behind the level of changes we're doing and the real benefits of hooks - while I'm actively going to be encouraging hooks, I want people to understand not only the 'how' but the 'why' as well. Remember, those modders who migrate from SMF are going to initially want to reuse what they've done before,
and while I'm not planning on pruning the package manager that far, I really don't want to encourage them to continue bad habits.
I want them to learn new ones, better ones, ones that will help them grow as developers, knowing as I do that most mod writers are not professional grade programmers.
$modSettings is for modifiable settings, it contains the contents of the admin panel's options that are forum wide (as opposed to $settings which is theme wide and $options which is user-centric) that are modifiable through the admin panel without editing any files, and is the general home of modification settings too.
But, see, what if the modder wants to do something in that place, but unrelated to the list of actions?
I think modders can start using hooks, as long as we provide them with a dummy mod that would show the correct ways of doing things. (Or some prominent mods start using hooks and they look into their code.)
And as I said earlier, we really should rename the hook functions, too.
Yeah, beginning with $context['user']...
I'm not much of a fan of anticipation, not because it's extra work for us, but more likely because if we start adding hooks in useless places, like at the beginning of every single function, it will waste CPU time for everyone, possibly for nothing.
Maybe for the most important mods, if there are any, we could offer the modder to convert their mods for them.
I think a good policy would be to add a warning when installing a package. In red.
Yes, but it's not very instinctive, see?
I did that, actually, in a shoutbox I built; as part of the plugin system SimpleDesk had, I did actually add the same hook that the action handler routine has (though calling SD's hook rather than SMF having it), and abused the hook to not only add my action but also to receive the AJAX calls and handle them, as well as manipulating $context at the same time.
Well, they were designed for integration which is where the name comes in, but sure, we can rename them to be more appropriate.
I still have no idea why that exists when $user_info contains virtually everything you'd want to know anyway.Quote Yeah, beginning with $context['user']...
I wasn't going to do it that way, I had a simpler plan - once the action handler was known and the index knew where it was sending the user, I planned to add a hook before and after it has run (since some functions don't return back, and some users will no doubt want to expand upon what's already been done). Yes, there is of course a performance hit there, but the increased flexibility more than makes up for it.
/melikes that idea.Quote I think a good policy would be to add a warning when installing a package. In red.
You want SD to be ported to Wedge, don't you...?
Integration is its purpose, but it shouldn't be its definition. Its definition is a hook.
Imagine that instead of calling parse_bbc(), you had to call parse_bbc_into_an_html_string()
Me neither. Probably another example of two vars that developed at pretty much the same time and were favored by one dev or another... Or they wanted to have the "me" equivalent to you's "$context['member']" or something.
Yeah, adding hooks in the main callee is perfectly fine and I would recommend it, too. Just don't add hooks in every Subs.php function, that's all
I'm sure most modders will work into making sure their modifications are all turned into hooks at that point.
(It's that's possible, of course. But right now I can't think of anything that isn't.)
$context['member'] actually makes sense for the most part since its main use is in the profile area when you're looking at another user's profile,
That's not anticipation, that would just be stupid :PQuote Yeah, adding hooks in the main callee is perfectly fine and I would recommend it, too. Just don't add hooks in every Subs.php function, that's all
A lot of the really little tweaks currently published as mods would be tricky to implement directly because of what they do - rearranging little bits of templates, and realistically, those are not possible to hook simply because of the mess you get into because you'd be adding hooks for every single minor point.
To a point you're getting into the game of second-guessing the developer intent, and without any secondary information, it's hard to be sure.
Remember, the integration functions were originally for linking SMF to a third party app, so reset_pass makes sense there, because what you're doing is when a user changes their password in SMF, you're flagging a routine in A.N.Other system to update the same user's password there too.
I'd argue in that case, there shouldn't be a need for the value to be byref. Other instances, however, yes it should be a byref, particularly if it seems logical for a third party app to want to modify something before SMF has its wicked way with it.
We're sort of taking that idea and expanding on it, meaning that any original purpose is likely now somewhat irrelevant. For each hook, look at where it is, what local variables are applicable and make a judgement call as to whether it is reasonable and appropriate for third party code (of any kind) to be modifying that. reset_pass is one case it shouldn't be necessary, for example.
There are instances where arrays are stored in $modSettings. None of them are consistent (e.g. the signature settings is a comma-separated value list, the censored words good/bad lists are newline-separated items, as are news items)
Storing an array is fine, but I personally wouldn't make it automatic, because you only have to unserialise it again later - and unless you're going to maintain a list of those things, you won't know what to unserialise en masse at the start.
Neither is integrate_eggnog but hey, who's counting?
magic_quotes shouldn't really be needed though (only for those really weird CMSes that do strange mystic things when magic quotes is enabled)
Do you think 64KB (the max variable length (TEXT) in wedge_settings) will be enough to store all possible hooks...?
Maybe for the most important mods, if there are any, we could offer the modder to convert their mods for them.
For the ones that aren't in the core itself, I'll likely put some time aside to sit and implement some of the smaller ones, partly as an example of 'how-to' and partly so we have that functionality available for people. But I'd definitely want to work with mod authors to help them make the jump.
That's the other way around actually.
And you are.........?
Where did you find this website?
Although, I see now it's still not supposed to be public?
You are welcome to delete my posts & account.
Thanks, and good luck with the project. Looking forward towards it's release...
As indicated, it won't be out before SMF2 Gold is ready, unfortunately
Officiously, there's nothing preventing them from going BSD as of now, of course. But what's happening is that they still have a dozen bugs or so to fix -- they're actually easy to tackle, but I'd venture into saying that all of the dev team is exhausted at this point.
Can you realize that both Pete and I were rumored for a proper developer spot at some point last year?
Duke Nukem Forever - even with its latest delay - will be out before SMF 2 Gold.Quote As indicated, it won't be out before SMF2 Gold is ready, unfortunately
The Wedge one, "Simple Math. Really"
Like, $smcFunc. What does SMC mean? Most people don't know. (And I don't even remember, myself.)
$wedgeFunc is too long and $weFunc may sound like "we fuck", so... $wf?
Might as well use $cx and $wf. And then document the change somewhere.
I think we already established that ToxG, as excellent as it is (given that it was made by talented people!), would be a no-no for as long as it can't allow mixing (if only temporarily) PHP templates with tox templates... :^^;:
Good call.Quote from Nao/Gilles on March 30th, 2011, 12:14 AM I think we already established that ToxG, as excellent as it is (given that it was made by talented people!), would be a no-no for as long as it can't allow mixing (if only temporarily) PHP templates with tox templates... :^^;:
As much as I love the mod/template solving of ToxG, its something that shouldn't be needed in the first place(mods modifying templates) and I really like to keep the PHP parts. :)
Yeah, modifying the output isn't the same as modifying the template. Anything that's fragile enough to require editing the template itself is going to hit problems sooner or later.
Why not $wtf? :lol:
So... Dragooon, what do you think we could do, either by adopting ToxG or by using a purely PHP solution?
2 things id like to comment on: integration hook system and template system. Integration hook system. Think of a switch statement. You have a list of conditions and a default. The very nature of a switch is faster than a nested if.
Make a small c prog and look at the machine code/object code.
Instead of waiting till you get there to ask and see if there is a hook, already know when you get there. The theory is in my head but it is difficult to express in words. Each action has a path. Find out if that action has a hook then contenue through the action then knowing the path needed to go. Make hooks one of the first things done when an action is requested by way of a switch.
Use switches in every possible time, instead of ifs.
Dont use memory/hd unless there is no other way to do it. Mysql and apache are already using resourses, reuse those in every conceivable fashion instead of drawing more resources. If you dont need a particular setting, dont load it. Even comments generate more lines of code cause it has to determine if it is a comment or not.
Think of a switch statement. You have a list of conditions and a default. The very nature of a switch is faster than a nested if. Make a small c prog and look at the machine code/object code.
Find out if that action has a hook then contenue through the action then knowing the path needed to go.
Make hooks one of the first things done when an action is requested by way of a switch.
Template system. 100% static.
Only echo predefined values. Gives modders a way of changing the template, without changing the template.
Mysql storable, cacheable.
Different templates for different days, so to speak
Use switches in every possible time, instead of ifs.
Dont use memory/hd unless there is no other way to do it.
Mysql and apache are already using resourses, reuse those in every conceivable fashion instead of drawing more resources.
If you dont need a particular setting, dont load it.
Even comments generate more lines of code cause it has to determine if it is a comment or not.
What im saying is, preprocess, process, display using as few steps as possible.
Dragooon, I thought you said you had a PHP template hook in mind?
Dragooon, hooks aren't a sad practice. They're actually one of the most practical solutions to the problem of customizability... The only point is that we have to be careful how fast execution of empty points is.
Basically, in Wedge, it's as fast as en empty() test. At this rate, we could very well set hooks every other line in the code without it becoming significantly slower. (We will, instead, stick to adding hooks where it seems reasonable enough. We will probably add more hooks during the alpha and beta sessions at the request of modders.)
I do hope PHP in Wedge's templates isn't taken out, since thats whats currently keeps my interest lmao. :)(not that I expect Wedge to stop because of me though ;) )
I have spoken in favor of TOXG before, but I just don't see the kind of freedom with it that PHP templates providest, sorry to say. If anything it seems more cumbersome to MIMIC using PHP than just use PHP right away.. The mod/theme problem is VERY well solved by it though..but if there won't be a problem why use it then?
As for templates not being allowed to use PHP, because its "dangerous" or "not to be trusted"..wake up I'd say. One of most widespread scripts around use PHP in their templates(and not only WP either) and they haven't wreaked havoc yet! I would imagine that for those that seldom make templates or just change a color here and there, the idea of using nice formatted HTML that fit just right into Dreamweaver, is a must-have.
For everyone else though, the benefits are very clear. And last I checked it was the actual CONTENT that was considered risky allowing too much freedom for - not the design.
I like my car to go from spot 1 to 2 without breaking down and being reasonably fast. I don't care if it can actually fly because theres no allowed areospace for it to fly in anyway...
TOXG was made by Unknown to solve a specific problem. If said problem doesn't exist anymore(or will not exist)...why have that car with wings that you can't use? It would actually require more resources(=fuel) because of the added "feature".
Just saying. :)Posted: March 31st, 2011, 06:40 PM
oh, and talking of doing stuff in tempaltes which isn't possible otherwise..there just isn't many(=none) around that actually utilize the power of said PHP we have now - in SMF - so I won't hold my breath that TOXG will be any different in that respect.
TBH manually positioning every hook in every bit of template is a very impractical practice, it may seem workable in theory but I don't see it actually working out. Hooks in actual workflow is a lot more sensible and practical thing.
$theme_function = 'template_' . $sub_template_name;
if (function_exists($theme_function))
$theme_function(); $theme_function = 'template_' . $sub_template_name;
$theme_function_override = $theme_function . '_override';
if (function_exists($theme_function_override))
$theme_function_override();
elseif (function_exists($theme_function))
$theme_function();The thing is, Tox-G adds a lot of possibilities otherwise which I consider to be quite hard doing with pure PHP without actually limiting a designer.
I haven't encountered a thing that I can't do with pure TOX-G. But to each it's own, PHP got its own advantages. One of my main motives of advocating TOX-G is because of it's hookable nature,
and i have a sig defined, but it doesnt appear to show up? does this custom version of smf yall are using require something that i dont know to set?
Will you add a template hook at every place possible?
Posts user info, post options, below one's sig, above post's title, above topic's title, below post's listing, below and above quick reply, quick reply itself, how about editing an existing template itself? Hooks are a lot more sensible on workflow itself, hence they work fine at controller and model stages but not at the view part.
| 1. | As opposed to nesting multiple template layers. |
Anything you want, really. We could discuss it in private if you'd like, or just keep doing it here. (Funny, this is technically the first development thread we're having in a public place...)
Wait, I did reply about TOX-G's exact abilities, what are you trying to ask? How it works or what advantages it has over PHP?
As far as TOX-G's functioning go :
1) Every template is defined in a XML like manner, you know the syntax.
It is easier to follow then pure PHP
2) Every template can be altered to add an overlay before or after it, I believe every template can also be replaced but I haven't experimented with this.
3) The template's files themselves are in a XML-esque manner which make sense for someone who don't know PHP but wants to do designing.
| 1. | I'm serious when I say I did my best to compensate for jQuery's download size... And these guys are adding more kilobytes to it on every single release, what the fork >_< |
i am merely expressing an alternative way of looking at the hooks concept.
and i use commas and periods dammit. lol
and yall = wedge, nao, and arantor
i guess you never been to texas.
well you ought to. lol
If they don't know PHP at all, is there a reason for them to know about XML..?
And as far as I can remember, broken XML (even slightly broken!) means broken *everything*? Unless Unknown wrote a custom parser that accepts any errors in the XML output... And/or the actual XML is treated as HTML, in which case everywhere you put some actual XML for ToxG's use, it will still fail horribly... (Let's say you type < tmp:something >, will it be parsed correctly? I know I'm quite torn myself whether or not I should add support for loose whitespace in my styling blocks...)
XML(Or TOX for that matter) isn't more difficult to understand for programmers, it makes sense if you read it, seriously, give it a shot(10 minutes max), I'll give you some sample templates from my project if you want.
XML is a far more wide adaptation than PHP, more than that, it is easier to understand than PHP's syntax.
Unknown's syntax is based on XML, but it is not strict XML per se. TOX-G uses a custom parser and not any standard parser(It doesn't even need the most basic XML plugins for PHP).
Hence the reason I could implement <we:if "expression">, < tpl:something > will not break things since it'll be treated like a string, <tpl:something> will since tpl is a reserved namespace and it is unclosed, but it'll give a nice error message! And yeah, TOX-G can self-close tags :P.
man i love you and arantor, yall are the coolest Europeans i know. :)
I'm unlike most anyone you have ever met, American or not.
I started programming with a TI-81 calculator. When i went to college in 2002, I had never seen the internet but a few times. Since then, however, i have embraced it, almost completely, in one form or another. I have 6 computers, 3 vps's, and 4 domain names.
What I am expressing in past posts is not theory or an example of practice. It is merely raw logic from more than half a year of customizing my own version of SMF, at the same time you were.
It may not appear so at times, but i come with only good tidings and my best advice/input that i can come up with.
@Dragooon> But you never actually asked for Consultant status...?
Pete, what about the template hooks I discussed earlier?
@Dragooon> Why would it piss me off?
You're an excellent coder, I had a thrilling experience with you on SMF Media Gallery, I like you, and although you're occasionally upsetting -- who am *I* to speak? :lo:
Pete> I noticed you weren't there much today... Is it gonna be okay?
And Dragooon -- you know the drill I suspect? No sharing what you get with anyone (not even your dad). If you have any doubts, ask us in private!
Wait, I can actually commit?
I'd like to make it mandatory for everyone to post a blurb about themselves before posting in these boards, but I don't like enforcing rules... I believe in freedom, but sometimes it's hard to get along with everyone when they just come, post what they have to post, and leave. See what I mean?
...
I will only resort to libel, slander and vilification to get someone out of my way. That's who I am. 8-)
Isn't defamation the SMF team ways as well? Didn't they use defamation to get you out of their way? :DQuote from Nao/Gilles on April 19th, 2011, 05:19 PM I will only resort to libel, slander and vilification to get someone out of my way. That's who I am. 8-)
I am aware that truth is an excuse for defamation, but lies are not. I know you don't lie. ;)