« Password Hashing
Template skeleton!
Zencart and a forum »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #90, on October 10th, 2011, 05:55 PM »
Quote
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.
It's not the worst idea you had this week. I'm not sure what is, but this wasn't it.

No, essentially what is needed is adding something to the topic - not the message - to define where it is. That takes care of content management internally.

All you do, much like I talked about for media items, is convert the board id into half of two columns: you have 'topic type' and 'topic context'; the type refers to board, or media item or whatever, and context is the board id or album id.

Displaying that content is another matter entirely, because then it comes down purely to presentation how you want to display it - since you'd realistically never use the same layout everywhere. The layout for posts (be they forum or blog posts) wouldn't be the same as in the PM area, wouldn't be the same as comments in media items, and whatever else (I certainly wouldn't reuse the same layout for WD, I'd keep closer to WD's original layout)

To sum up, it is exactly what you're talking about, but tied to the topic, not the individual message. A given message lives in a given topic. It's the topic which forms a collection of messages that you need to deal with putting an origin into.
Quote
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().
Then it doesn't really need to belong to the class, though there's no reason why it *can't*. It is sort of between the two, go with whatever makes more sense.
Quote
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...
So you're merging then? :P Consider array_merge. It replaces elements in the first source with those from the second, and is quite content to add things on the end as well under the right circumstances...
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #91, on October 10th, 2011, 07:45 PM »
Quote from Arantor on October 10th, 2011, 05:55 PM
It's not the worst idea you had this week. I'm not sure what is, but this wasn't it.
I think I should feel offended... :lol:
Quote
No, essentially what is needed is adding something to the topic - not the message - to define where it is. That takes care of content management internally.
Then that's exactly the original definition of floating topics...
Quote
All you do, much like I talked about for media items, is convert the board id into half of two columns: you have 'topic type' and 'topic context'; the type refers to board, or media item or whatever, and context is the board id or album id.
Which also means we can't have both a topic ID of #1 and an album ID of #1. Or we have to ditch the id_topic key in favor of an (id_topic, board_type) key. Which I'm not sure would be as fast...?
Quote
Displaying that content is another matter entirely,
Definitely. I was still referring simply to the storing of data itself.
Quote
Then it doesn't really need to belong to the class, though there's no reason why it *can't*. It is sort of between the two, go with whatever makes more sense.
A shorter wetem is what I'm looking at for now.
Quote
Quote
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...
So you're merging then? :P Consider array_merge. It replaces elements in the first source with those from the second, and is quite content to add things on the end as well under the right circumstances...
Don't confuse me... :whistle:

I'm already confused enough with the merging (ahah) of ::load and ::layer... And actually I shouldn't do it, really. I think.

Take an example...

::load(array('layer' => array('block')), 'default', 'replace')

Okay, what do you do with this...?

- loadBlock() would do this: take the 'default' layer, empty it, except for its child layers. Then add the contents of the array to it. i.e. we would have <wrapper><default><layer><block /></layer></default></wrapper>.

- loadLayer() would do this: take the 'default' layer, and REPLACE it with the 'layer' layer. We would have this: <wrapper><layer></layer></wrapper>.

So, I went ahead and added a 'rename' value for ::load() not to get confused, but what to do in our example, where I'm providing contents for the layer? Should I also empty out the original layer and add data to it? Or should I just rename the layer, and don't bother with the provided contents...?
So much fun for me...

I guess I'll just keep the ::layer method for easy addition of container layers, like used to be done in SMF.
And I'll consider calls to ::load to be, well... Just a series of blocks.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #92, on October 10th, 2011, 09:17 PM »
Quote from Nao on October 10th, 2011, 07:45 PM
I think I should feel offended... :lol:
Nope, wasn't meant as one. There simply haven't been any bad ideas.
Quote
Then that's exactly the original definition of floating topics...
Yup, hehe ;)
Quote
Or we have to ditch the id_topic key in favor of an (id_topic, board_type) key. Which I'm not sure would be as fast...?
You'd make id_topic remain the PK, then have a unique index on source_type, source_id. It'd be comparable to now, and should be faster under some circumstances.
Quote
Definitely. I was still referring simply to the storing of data itself.
*nods*
Quote
A shorter wetem is what I'm looking at for now.
Works for me.
Quote
Don't confuse me... :whistle:
Heh. Well, just seems to me that add (or better, merge) is the right verb to describe the operation being carried out.
Quote
::load(array('layer' => array('block')), 'default', 'replace')

Okay, what do you do with this...?
This says to me to replace the current contents of default with a new layer (with that new block in it)

The rename is a good idea.
Quote
I guess I'll just keep the ::layer method for easy addition of container layers, like used to be done in SMF.
And I'll consider calls to ::load to be, well... Just a series of blocks.
Works for me.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #93, on October 10th, 2011, 09:59 PM »
Quote from Arantor on October 10th, 2011, 09:17 PM
Nope, wasn't meant as one. There simply haven't been any bad ideas.
You can always try, but you'll have a hard time trying to offend me, given that I'm convinced that whenever you criticize me, it's because I deserve it, not because you want to offend me ;)
Quote
You'd make id_topic remain the PK,
...which, again, means we can't have both a topic=1.0 and a media album with ID #1. Creating a first album when topic=1.0 already exists will set the album ID to 2. And that's precisely one of the major blockers for me...
Quote
Heh. Well, just seems to me that add (or better, merge) is the right verb to describe the operation being carried out.
Right now I'm staying at ::load(), waiting for feedback.
Quote
Quote
::load(array('layer' => array('block')), 'default', 'replace')

Okay, what do you do with this...?
This says to me to replace the current contents of default with a new layer (with that new block in it)
Exactly... Except if you replace $blocks with array('layer' => array('block'), 'block2'), it's exactly the same except that we want to add another block right after the layer... So, technically, should Wedge behave completely differently (i.e. replace the contents of the layer rather than the layer itself) just because I added a block to the list...?

Working on replacing _above and _below with _before and _after... It's quite odd. Oh, and there's an even stranger one -- Reports.php has both a 'print' layer and a 'print' block. UH!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #94, on October 10th, 2011, 10:05 PM »
Quote
...which, again, means we can't have both a topic=1.0 and a media album with ID #1. Creating a first album when topic=1.0 already exists will set the album ID to 2. And that's precisely one of the major blockers for me...
Wait, what?

The boards and albums table will be left alone, because they're foreign keys to the source-type/source-id item.

If you create a board, and an album, they're both id 1 in their respective tables.

The first topic to be created is topic id 1 (source type: board, source id 1, as it's in board 1). Then we upload a media item... it's media item 1 (in album 1), but it consumes topic id 2 (source type: album, source id 1)

You can define multiple types of index on a typical; topic own id has to be the primary key because it's auto-increment and that ensures uniqueness for the topic itself (so you don't end up with multiple topic id 1 cases)

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #95, on October 10th, 2011, 10:43 PM »
Quote from Arantor on October 10th, 2011, 10:05 PM
Quote
...which, again, means we can't have both a topic=1.0 and a media album with ID #1. Creating a first album when topic=1.0 already exists will set the album ID to 2. And that's precisely one of the major blockers for me...
Wait, what?

The boards and albums table will be left alone, because they're foreign keys to the source-type/source-id item.
But if id_topic is the primary index, then it's unique as well, isn't it..? So we can't hold two different items with id_topic = 1 in the topic table... (Can we?)
Quote
The first topic to be created is topic id 1 (source type: board, source id 1, as it's in board 1). Then we upload a media item... it's media item 1 (in album 1), but it consumes topic id 2 (source type: album, source id 1)
Then we can't have a topic=2.0... Same problem. No?
Or do you mean to store the actual topic IDs in a different place than {db_prefix}topics...?

(Also, FWIW, I've updated the demo site to the latest SVN... Except I haven't updated the database, so it's bound to crash on the missing items.)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #96, on October 10th, 2011, 11:29 PM »
Quote from Nao on October 10th, 2011, 10:43 PM
But if id_topic is the primary index, then it's unique as well, isn't it..? So we can't hold two different items with id_topic = 1 in the topic table... (Can we?)
No, that's because it's auto increment and thus unique.
Quote
Then we can't have a topic=2.0... Same problem. No?
Or do you mean to store the actual topic IDs in a different place than {db_prefix}topics...?
Same problem. Might as well scratch the idea of floating topics since it cannot be implemented in a way that to be able to have contiguous user visible topics without making it over complicated (by having the user visible id be separate and disconnected from the physical id, because you then have to get into the realms of transactions to ensure that the id you use for insertion is actually the next id and hasn't been stepped on in the time between querying for last-used id and the row insertion...)

If the choice is between having separate tables or juggling ids, I'll take separate tables every time.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #97, on October 10th, 2011, 11:32 PM »
Hmm. And if we only created dummy topic Ids each time a comment is posted on a profile or album or item?
we could associate these dummy Ids with the real element Id in a new table... Dunno.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #98, on October 10th, 2011, 11:33 PM »
Quote from Nao on October 10th, 2011, 11:32 PM
Hmm. And if we only created dummy topic Ids each time a comment is posted on a profile or album or item?
we could associate these dummy Ids with the real element Id in a new table... Dunno.
Which is juggling ids, which is more work, requires transactions to achieve reliably, and complicates matters.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #99, on October 11th, 2011, 12:47 AM »
Profile comments and Media comments = less used, less likely to have lots of items, less likely to be a pain in the ass to maintain, IMHO.
Re: Template skeleton!
« Reply #100, on October 11th, 2011, 12:53 AM »
Totally unrelated (again)... Would post in the 'These two bytes won't matter to you' topic, but I have a post to answer over there and if I post this, I'll forget about the other one ;)

I tried running minification processes on inline JavaScript. I took the media homepage as an example.

Running nothing: about .08s to execute the page
Running JSMin on the whole page: about 0.17s
Running Packer on the whole page: about 0.38s

Additionally, Packer tends to crash the page in some situations...
So JSMin is definitely the winner here.

However, it still doubles the time needed to generate the page... Which would be fine if it saved a lot of data, but it isn't the case.

Full page: 33759 bytes
Compressed: 32107 bytes

So it saves about 1.6kb...

Which is reduced to about 400 bytes after zipping the files.
About 4% saved on the full size.

I'm not exactly sure it's worth it... Sure, it's good for bandwidth (that's 400 bytes saved on *each* page load), but if it makes page generation twice more expensive... Not sure it's worth it.

Does anyone know of a PHP script that can compress JavaScript on the fly VERY quickly? And I mean, VERY?
I don't mind if it isn't optimized for size... I need something that optimizes for speed!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #101, on October 11th, 2011, 01:16 AM »
Quote
Does anyone know of a PHP script that can compress JavaScript on the fly VERY quickly? And I mean, VERY?
I don't mind if it isn't optimized for size... I need something that optimizes for speed!
I don't think there is one. Packing JS is not normally a JIT type process, it's done in batch and pushed out once done. Even the likes of JSMin and Packer are not designed for JIT and not really in the manner in which Wedge uses them (which is about the closest to JIT I think you're going to get)

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #102, on October 11th, 2011, 01:18 AM »
I'm just pretty sure there's a way to minify these with little overhead even at the cost of limited gains.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #103, on October 11th, 2011, 01:28 AM »
Question: what happens to the size of the file before and after with gzip?

I remember someone doing a test to shorten $scripturl to just 'index.php' instead of prepending it with $boardurl, and finding the gzipped difference was only 200 bytes. I wonder if something similar would be the case here.

I also wonder whether it wouldn't be worthwhile stripping \s{2,} from the buffer while we're at it (since bbcode/posted code is not subject to that limitation, as it's injected with nbsp entities during preparse)
Re: Template skeleton!
« Reply #104, on October 13th, 2011, 03:27 PM »
There's something still up with this, even with the latest changes.

So, I want to add a block to the info_center layer, before the statistics (info_center_statistics is the target block I want to insert before)

So, naturally, I'm thinking the call should be:
Code: [Select]
wetem::load('birthdays_info_center', 'info_center_statistics', 'before');

This promptly causes it to get very upset and throw the skeleton error. Oddly it only renders a very limited set of the page (it renders the everything except the <body> tag in the source HTML, so I get the headers, <head> and closing </html>)

More interestingly, I get:
Quote
http://smf/wedge/index.php
 2: Invalid argument supplied for foreach()
 File: C:/Dev/public_html/smf_test/wedge/Sources/Subs-Template.php
Line: 1440
in the error log. Line 1440 is the foreach in wetem::render_recursive that performs the iteration through the skeleton and either calls render_recursive again or execBlock. Logical, I guess, if the template structure is broken and that what it's being fed isn't an array.


You want to debug or want me to do it?
« Password Hashing
Zencart and a forum »