Skip to main content
Topic: BBC Parsing (Read 39582 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: BBC Parsing

Reply #135

Don't get mad at what? What's an untouched monster?

 

Re: BBC Parsing

Reply #136

parse_bbc I guess. :P
Bugs creator.
Features destroyer.
Template killer.


Re: BBC Parsing

Reply #138

Trust me, I know all of the intricacies of parse_bbc ()

Re: BBC Parsing

Reply #139

This might sound crazy, but BBC types should be classes. Their properties should be what they are allowed to do.

For instance:
Code: [Select]
final class \BBC\Types\ClosedType
{
 const HAS_PARAM    = false;
 const HAS_EQUALS    = false;
 const HAS_BEFORE    = true;
 const HAS_AFTER    = true;
 const HAS_CONTENT  = false;
 const PARSE_CONTENT = false;
 const PARSE_EQUALS  = false;
}

The idea would be to define the rules for each type in the code. This would be fleshed out more and the rules themselves would be defined (in documentation, don't need another class for that). One could then expand the types to make the individual codes lighter. With a syntax tree, it would also make parsing cheaper.

Re: BBC Parsing

Reply #140

Thats a very interesting idea nods I think it would further clean things up  .... I'm not convinced it will make parsing cheaper but you did surprise me with how well your new parser works ;)

I saw you made the commit and then pulled it back, rebase problem or are you still doing some restructure?

Re: BBC Parsing

Reply #141

Totally screwed up the repo. Pulled commits from other branches, merged and committed after. Emanuele fixed it on his repo.

Re: BBC Parsing

Reply #142

git noob :P

I never mess up my repos.   OK truth is that I had to increase my beer budget after I started using git ... I'm hoping there is a link there :P

Re: BBC Parsing

Reply #143

I didn't send the PR because I thought you (Josh) wanted to remove the install-related commits, but if it is okay like that I can send it. ;D

ETA: dammit it's still broken! xD
And the tests fail too... :(

I'll try to rebase it again soon.

ETA2: this is the branch https://github.com/emanuele45/Dialogo/tree/BBC2
Last Edit: December 02, 2015, 05:24:08 pm by emanuele
Bugs creator.
Features destroyer.
Template killer.


Re: BBC Parsing

Reply #145

Ok, fixed the tests as well.
Now I only have one doubt: ILA (still) relies on the message id passed by the integrate_post_parsebbc to the ILA function, though with the new parser the id_msg is (correctly) not passed, so we are a bit left without a piece there. It should still work because 'msg' should be in $_REQUEST, but it's a weak assumption, it may work for beta, but a final solution should be found.

Apart from that I guess it could be ready for work. ;D
Bugs creator.
Features destroyer.
Template killer.

Re: BBC Parsing

Reply #146

Where does it need the message id? What does it do with it?

Re: BBC Parsing

Reply #147

To get the attachments of each message.
The first way I see to avoid this requirement is to change ILA behaviour using the id_attach instead of going with the number of attachments in the message (though, that would make kind of hard to guess attachments id in posts, unless we use an "unique" random number that is later replaced with the attachment id (sort of what github does).
The second is to attach ILA somewhere else where the id_msg is available.
Bugs creator.
Features destroyer.
Template killer.

Re: BBC Parsing

Reply #148

Quote from: emanuele – The first way I see to avoid this requirement is to change ILA behaviour using the id_attach instead of going with the number of attachments in the message

that will give you less headache in the future with openimporter, other forum scripts are using inline images with the id of attachment
sorry for my bad english

Re: BBC Parsing

Reply #149

Yeah, I would just put the attach id as the id used there. 1, 2, 3, etc is just as, if not more confusing than the attach id.