Skip to main content ↑ ↓
Topic: My Elkarte2 Repo (Read 2554 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

My Elkarte2 Repo

https://github.com/joshuaadickerson/Elkarte2

IOT understand the changes, go check the commit log. There's going to be too many for me to list them in one message. It all started because the current autoloader was annoying me and I wanted something PSR-0/4 compliant.

Re: My Elkarte2 Repo

Reply #1 –

 Eliana Tamerin is tempted to submit an issue for the readme, featurelist mimics Elkarte 1's. ;)

Still, 10,000 commits is no small feat. Bravo, Josh.

Re: My Elkarte2 Repo

Reply #2 –

Feel free to submit issues. It will help me remember things like that. A lot of the directories will have their own README.md files so I can explain what they do.

As for the commits, it's not really that much. It's just moving files, fixing namespaces, and removing static stuff. It takes a lot of work, but it's not really technical and a lot of it is done with search and replace.

Re: My Elkarte2 Repo

Reply #3 –

Not to take a thing away from the work that has been done here, but I wanted to comment on the commit numbers.

The 10K is because its a fork of the 1.1 branch which has ~12K commits on it.  That includes of course all the 1.0 commits plus any of the 1.0.x update commits (~10K there).   Its not 10K commits in just the 2.0 branch, its a cumulative number from day 1.

So thats 12K commits from when SMF revised the license conditions and released it under BSD.  If you look way way back to commit #1 it will say 10610 which was the SVN version of the first BSD release,  its that version that I used when I first loaded the github repo.  Likewise the delta between ElkArte master and development is ~2k,  meaning ~2K unique commits in 1.1   At least that is my understanding of those numbers.

Whats great about git, it really has a history tree, so you could start with an SMF repo of 10610 and apply all those commits and get whats in the repo today, or apply them to a branch point, fork it and go from there as well.  I think the challenge for that 2.0 branch will how well it rebases 1.1 commits.  @emanuele  would know for sure since he has done all of the 1.0.x incremental commits back into the 1.1 branch, that level of git is above my pay grade.

Re: My Elkarte2 Repo

Reply #4 –

ehh...
yeah, merge stuff in would be a pain. In a case like that, I think the best way is to track down all the relevant commits done and port them one by one (or maybe in batches with some scripting trickery).
Bugs creator.
Features destroyer.
Template killer.

Re: My Elkarte2 Repo

Reply #5 –

Yeah, I don't think it would work. I am okay with porting changes forward. I will start writing tests for classes soon so you might actually start seeing things that need to be backwards ported.

Re: My Elkarte2 Repo

Reply #6 –

Let me explain how Context is going to work. It will no longer be a global variable. It will be a class named Context (probably changing the name to represent that it is a repository of decorators). Context will contain handlers (or decorators). It will be exposed to templates and controllers as $this->context.

For templates, the main method you'll use is Context::get(). You'll pass an object to it like this:
"while ($board_context = $this->context->get($board))" where $board is a Board object. That returns BoardContext. Now, instead of calling getBoardParents() for each board in loadBoard() or wherever, it will load that when necessary. So Board is just what goes in to and comes out of the database in simple terms. ContextInterface has two methods: hydrate() and supports(). hydrate() adds the values and supports() checks if the object is supported.

For the controllers there are a few methods in the Context class. $context is part of the view. It gets injected in to the templates class but all of the handlers are done from the controllers.

There's a lot more to talk about it but you'll see it in code which will make a lot more sense. When I get it coded, then I'll write better documentation ;)

Re: My Elkarte2 Repo

Reply #7 –

I don't know if you are already thinking about it, though one thing I was considering for 2.0 was/is something like symfony's http kernel: the request is passed to the controller that returns an object that is then passed to the template.
In my mind was something along the lines of:
Code: [Select]
$dispatcher = new Dispatcher($action);
$controller = $dispatcher->dispatch();
$request = $controller->getRequest();
$theme = new Theme($request);
$theme->render();

I'm not sure it's worth of it fits the general design, though I think it's worth mentioning. :P
Bugs creator.
Features destroyer.
Template killer.

Re: My Elkarte2 Repo

Reply #8 –

I didn't realize Symfony worked like that. Using Silex it would be more like {add services}, $app->run(), {find route, dispatch to controller}, in the controller find the template to render, return $twig->render($template, [vars]); and then it will return a Response. That's what I was thinking.

Your way makes sense too. Instead of the front controller just pretty much passing through it gets a TemplateResponse (or something) and then render() would be called outside of the controller.

Re: My Elkarte2 Repo

Reply #9 –

Well, I never really understood how Symfony works. What I described is just what seemed to make sense to me, but of course other ways are good as well. :P
Bugs creator.
Features destroyer.
Template killer.