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 - Arantor
6166
Plugins / Re: Add-on Manager: Mechanics
« on October 3rd, 2011, 09:05 AM »
There's the thing: once it's done, it's done and it can be used to automate testing of plugin-info.XML files.
6167
Plugins / Re: Add-on Manager: Mechanics
« on October 3rd, 2011, 03:06 AM »
Getting back to the DTD, I found the whole process of trying to set out the DTD fairly frustrating, since I concluded that I didn't want to have to set the order for every little thing, so in the end I started experimenting with RelaxNG instead. Similar idea but you write it in XML instead of some arbitrary format, and while validation is slightly more effort, the specification is easier to maintain IMO.
(See, I discovered that even the different miniature plugins I had didn't really conform to set orders of things, and I found it fairly irritating to have to set even the order of name/description/author/website in that order.)
I've written the bulk of the RelaxNG spec, just debugging it at the moment, it weighs in at 462 lines :/ - and it only covers about 3/4 of the actual specification.
(See, I discovered that even the different miniature plugins I had didn't really conform to set orders of things, and I found it fairly irritating to have to set even the order of name/description/author/website in that order.)
Posted: October 3rd, 2011, 01:23 AM
I've written the bulk of the RelaxNG spec, just debugging it at the moment, it weighs in at 462 lines :/ - and it only covers about 3/4 of the actual specification.
6168
Features / Re: New revs - Public comments
« on October 3rd, 2011, 12:23 AM »It's only an icon cache... I'm caching ALL of the icons in the array, regardless of whether they can be shown to the user. Small enough anyway.
I still haven't looked at the code, but I really hope it's checking whether it's a URL or not, because otherwise it's likely to be calling for a plugin's icon(s) through an external URL request only to be served locally... (I couldn't see any way of passing just a filename to the menu builder and for it to be able to cope with it, so the menu builder looks to see if it's a URL or not, and if not, serves it from the theme as normal)
6169
Plugins / Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 2nd, 2011, 06:40 PM »
Heh, well, the title might have given you a clue what's going on.
In order to more thoroughly test the plugin system, and indeed a few other things while I'm at it, I'm slowly going to be writing some plugins for Wedge. Most of them won't be huge, in fact I suspect a number of them will fall into the tweaks category, and no doubt I'm going to have to patch them as Wedge itself evolves, but it's a good indicator that I'm on the right direction if I can build these.
Two things:
1. This IS NOT a requests thread. DO NOT request plugins. I'm not taking requests, nor functionality requests for things I've already mentioned here. They will be published when I'm ready and not before.
2. I'm not sharing the plugins here. Apart from the fact that they're likely to need changes as Wedge evolves, you can't even get Wedge yourself yet. And even if you could, it's likely that something will break as things go on, so that until Wedge is at a stable position, there's no point in my handing out anything more than tiny code samples.
Anyway, the first one is a quick hack of the 'Users Online Today' functionality that's used here, though it's without configuration, options or indeed anything other than the absolute minimum functionality.
This is also interesting for me because it's the first time I've bent the rules about code placement. I think I've also found something up with the template skeleton functionality but that's another matter entirely.
Controversially, the entirety of the template and language strings are in the one file. Given that the template is 10 lines of code (and only 2 PHP statements, a global and an echo), and that I'm using 5 language strings out of nicety as 2 or 3 would probably do, with the entire plugin weighing in at 75 lines... having three files (source, language, template) seems just wasteful, and definitely inefficient.
But anyhow, here's a screenshot. It's nothing special - but it does work (after I added a hook to the board index, though I think I'm going to change that hook a bit to suit something else I have in mind). It won't look much different even if I do change that hook, though.
In order to more thoroughly test the plugin system, and indeed a few other things while I'm at it, I'm slowly going to be writing some plugins for Wedge. Most of them won't be huge, in fact I suspect a number of them will fall into the tweaks category, and no doubt I'm going to have to patch them as Wedge itself evolves, but it's a good indicator that I'm on the right direction if I can build these.
Two things:
1. This IS NOT a requests thread. DO NOT request plugins. I'm not taking requests, nor functionality requests for things I've already mentioned here. They will be published when I'm ready and not before.
2. I'm not sharing the plugins here. Apart from the fact that they're likely to need changes as Wedge evolves, you can't even get Wedge yourself yet. And even if you could, it's likely that something will break as things go on, so that until Wedge is at a stable position, there's no point in my handing out anything more than tiny code samples.
Anyway, the first one is a quick hack of the 'Users Online Today' functionality that's used here, though it's without configuration, options or indeed anything other than the absolute minimum functionality.
This is also interesting for me because it's the first time I've bent the rules about code placement. I think I've also found something up with the template skeleton functionality but that's another matter entirely.
Controversially, the entirety of the template and language strings are in the one file. Given that the template is 10 lines of code (and only 2 PHP statements, a global and an echo), and that I'm using 5 language strings out of nicety as 2 or 3 would probably do, with the entire plugin weighing in at 75 lines... having three files (source, language, template) seems just wasteful, and definitely inefficient.
But anyhow, here's a screenshot. It's nothing special - but it does work (after I added a hook to the board index, though I think I'm going to change that hook a bit to suit something else I have in mind). It won't look much different even if I do change that hook, though.
6170
Features / Re: Birthday greetings
« on October 2nd, 2011, 06:27 PM »6171
Plugins / Re: Hooking up data loading
« on October 2nd, 2011, 06:25 PM »
That was really why I documented the Mechanics thread, to explain how it worked, both at the author end and the technical end... :/
What about it isn't so clear?
What about it isn't so clear?
6172
Features / Re: Template skeleton!
« on October 2nd, 2011, 06:24 PM »loadBlock('my_block', 'info_center_useronline', 'after');
See the opening to loadBlock: it converts the target (info_center_usersonline) into an array and attempts to match that to $context['layers'], which if it found it, it would put it in $to, but it doesn't find it (because it's not a layer) and promptly returns.
Providing a fallback is fine, assuming it actually wants to do that. It might decide that if the desired place can't be done, it doesn't want to do a fallback - or, slightly more irritatingly, let's take something I considered for WedgeDesk. WD has a two column layout for the main ticket display, some of which I pushed into the sidebar - but if the sidebar doesn't exist, I'd be wanting to create a new template layer to hold things in. (Though, I guess, I could test for the sidebar before trying to add that block in the first place, but my point is: I might want to do other things rather than just having a direct fallback.)
6173
Features / Re: New revs - Public comments
« on October 2nd, 2011, 06:18 PM »
Some interesting things in r1049.
Probably the first one which occurs to me is:Quote Why? It wasn't part of $context originally for a reason: security. The only way it could be modified was through the defined hook, because as soon as it's been back from the hook, housekeeping is done then it's sent off to createMenu, whereupon it is discarded.Quote I'd rather automate that if possible. While it's not particularly ideal to sit and retest the entire menu structure for changes, if it's been to a hook, the hook is going to have added some items which will likely negate the cache.
What, exactly, is cached here? (I haven't looked yet.) I wasn't that fond in SMF of having things cached after hooks had been run, it seemed to defy the point of having per-run hooks and can lead to messiness after things have been disabled or even enabled. (Perhaps the plugin enable/disable steps should also clean cache generally anyway.)
That said, it seems to be purely CSS cached here, in which case only plugins that do... something... with CSS need to clear it? Let me know exactly what's being cached, or I'll figure it out from the source, whichever happens first, and I can then make a judgement as to whether the plugin manager should do that automatically or whether plugins that make a change there need to deal with it.Quote Icons are good. Unless they look massively out of place, they'll probably be fine and might encourage us to iconify the rest, which is generally a good thing.Quote I wouldn't worry too much about maintaining these files. As things evolve, these two plus Subs-Package are going to be phased out anyway.
Probably the first one which occurs to me is:
Also note that $admin_areas is now a global, so the admin menu hook doesn't need to specify it as a param.
if you modify the admin menu, you'll need to manually remove the cache file, or run clean_cache('css', 'admenu') through a hook or something.
What, exactly, is cached here? (I haven't looked yet.) I wasn't that fond in SMF of having things cached after hooks had been run, it seemed to defy the point of having per-run hooks and can lead to messiness after things have been disabled or even enabled. (Perhaps the plugin enable/disable steps should also clean cache generally anyway.)
That said, it seems to be purely CSS cached here, in which case only plugins that do... something... with CSS need to clear it? Let me know exactly what's being cached, or I'll figure it out from the source, whichever happens first, and I can then make a judgement as to whether the plugin manager should do that automatically or whether plugins that make a change there need to deal with it.
Added three icons to the topic moderation menu. Only visible to members with the correct permissions.
Package functions don't need to declare admin.css, since it's already declared by that time. (PackageGet.php, Packages.php)
6174
Features / Re: Template skeleton!
« on October 2nd, 2011, 06:09 PM »
OK, I think I found a limitation in the template skeleton, unless I'm missing something fairly big.
For my first plugin, I tackled a simple version of the 'users online today' functionality. Nothing clever, just literally getting all the visitors since midnight (subject to visibility)
Now, adding the template layer to the info_center layer is straightforward enough, but I can't place it before a given block inside that layer; ideally I'd place it after info_center->info_center_usersonline, but I can't see a way of doing that.[1]
Also, I'm thinking it might be useful to add a boolean return to loadBlock and its friends, in case we attempt to load but it isn't there - e.g. if the info_center->info_center_usersonline block doesn't exist, we would be able to detect that and display it somewhere else, or do something else with it at least.[2]
For my first plugin, I tackled a simple version of the 'users online today' functionality. Nothing clever, just literally getting all the visitors since midnight (subject to visibility)
Now, adding the template layer to the info_center layer is straightforward enough, but I can't place it before a given block inside that layer; ideally I'd place it after info_center->info_center_usersonline, but I can't see a way of doing that.[1]
Also, I'm thinking it might be useful to add a boolean return to loadBlock and its friends, in case we attempt to load but it isn't there - e.g. if the info_center->info_center_usersonline block doesn't exist, we would be able to detect that and display it somewhere else, or do something else with it at least.[2]
| 1. | It wouldn't be so much of a problem if it wasn't for the fact that there is actually already a block under usersonline, even if it is off by default. |
| 2. | E.g. we could test for it up front and if not found, don't bother running the DB queries and so on. |
6175
Features / Re: New revs
« on October 2nd, 2011, 05:16 PM »
Revision: 1048
Author: arantor
Date: 16:15:47, 02 October 2011
Message:
! Fix to installer failing to create correct key in database tables. (install.sql)
----
Modified : /trunk/other/install.sql
Author: arantor
Date: 16:15:47, 02 October 2011
Message:
! Fix to installer failing to create correct key in database tables. (install.sql)
----
Modified : /trunk/other/install.sql
6176
Features / Birthday greetings
« on October 2nd, 2011, 04:25 PM »
We really have to edit the default templates for birthday emails. They are distinctly a bit corny now :P
6177
Plugins / Re: Hooking up data loading
« on October 2nd, 2011, 04:11 PM »I am 1500 lines late on my plugin code review. I don't even know how it works...
6178
Off-topic / Re: Old layout vs new layout?
« on October 2nd, 2011, 10:06 AM »6179
Off-topic / Re: Doctor Who
« on October 1st, 2011, 08:57 PM »
So, the finale.
(click to show/hide)
Let me put it this way. The finale feels very RTD ish. But I'll be buying the season when it comes out and watching it through again because I suspect it'll hold up even better then.
Cute resolution, very clever, something I certainly didn't see coming. And it explains what the eye patches are all about, something that had been bothering me. And yet again, Rory being the hero, and (nearly) dying again.
It didn't feel too rushed, either, but the subtlety and ingenuity of things that had been hidden, had been layered was incredible. Notably, Byzantium-era River talking to present-era Amy - remember the conversation from The Time of Angels, of who Amy thinks River is, in particular.
Plus the question, that must never be answered - but it is, quite correctly, the first question. That's probably the most devious thing I've seen yet from Moffat, the question in plain sight. There was me thinking all Douglas Adams, too, but the question will be answered, as it must, at the fall of the Eleventh - and we KNOW it's been answered because the consequences of having the answer have already been seen.
Let me put it this way. The finale feels very RTD ish. But I'll be buying the season when it comes out and watching it through again because I suspect it'll hold up even better then.
6180
Plugins / Re: Add-on Manager: Mechanics
« on October 1st, 2011, 06:48 PM »
No, because the manager can't know when it should remove them, at least not reliably, since potentially you're talking about any row in any table. Plus, you run the risk of duplicating rows depending on the table in question.
If you need to do so, add a script in the <enable> block and do appropriate clean-up during <disable>, <remove> or <remove-clean>.
WedgeDesk does this when it auto creates a department on install, because the only way it can know whether to add that row is another query first - and that kind of logic can't be represented in a sane fashion in XML.
That said, give me a solid use case for adding it, ideally with a method to automate clean-up, but at least that can safely avoid duplicates, and I'll revisit it (it's not like the plugin manager is finished right now, it's sufficiently done that it's usable, but there's plenty to do)
Note that the two most common tables you'd need to manually add to (settings and scheduled tasks) have defined interfaces for that purpose, and if there's another table that's similarly likely to be updated, I'm happy to include an interface for that, but I'm not enthusiastic about a totally generic row-insertion setup, at least not without refinements to the idea.
If you need to do so, add a script in the <enable> block and do appropriate clean-up during <disable>, <remove> or <remove-clean>.
WedgeDesk does this when it auto creates a department on install, because the only way it can know whether to add that row is another query first - and that kind of logic can't be represented in a sane fashion in XML.
That said, give me a solid use case for adding it, ideally with a method to automate clean-up, but at least that can safely avoid duplicates, and I'll revisit it (it's not like the plugin manager is finished right now, it's sufficiently done that it's usable, but there's plenty to do)
Note that the two most common tables you'd need to manually add to (settings and scheduled tasks) have defined interfaces for that purpose, and if there's another table that's similarly likely to be updated, I'm happy to include an interface for that, but I'm not enthusiastic about a totally generic row-insertion setup, at least not without refinements to the idea.