Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(views): refactor views service to store absolute paths #8390

Closed
wants to merge 6 commits into from

Conversation

ewinslow
Copy link
Contributor

Replaces #7070

  • fix views inspector :/
  • developer settings not showing admin menu... may be unrelated to this
  • messages and friends menus disappear with this change... ??
  • htmlawed no longer working
  • fatal error in Elgg/CacheHandler.php
  • Performance needs to improve substantially
  • Fix plugin's views support
  • View rendering should not use hooks/extensions when rendering extensions

$params = array('view' => "$view", 'vars' => $vars, 'viewtype' => "$viewtype");
$content = $this->hooks->trigger('view', "$view", $params, $content);

// TODO: Remove backward compatibility with less granular hook in 2.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be removed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@mrclay
Copy link
Member

mrclay commented May 29, 2015

This looks great but feels like it would eat memory/perf. It's too bad we allow view configuration to be completely malleable at all times. I'll dig into it more a bit later.

@ewinslow
Copy link
Contributor Author

Yea... I just figure we can always optimize later if that actually becomes an issue.

I would like to make our views system more immutable. So you can't keep registering or changing views after the initial boot.

@ewinslow
Copy link
Contributor Author

Latest push fixes some end-to-end issues. I haven't tested performance or whether this is getting cached or anything like that.

I'm a little rushed because I'm strapped for time and this is blocking other significant improvements.

I do not plan on finishing implementing the incomplete tests before merging this. There are quite a few left but I already implemented way more than we had before so I'm feeling pretty good about that.

@mrclay
Copy link
Member

mrclay commented May 29, 2015

Worth a note here that this blows up and turns off htmlawed. Also
Call to undefined function Elgg\_elgg_is_view_cacheable() in .../Elgg/CacheHandler.php on line 58

@mrclay
Copy link
Member

mrclay commented May 29, 2015

Will be sending you fixes...

@ewinslow
Copy link
Contributor Author

Thanks.

@ewinslow
Copy link
Contributor Author

Some of these issues were caused by bad interactions with the pagesetup event.

@ewinslow
Copy link
Contributor Author

Moving some handlers out of the pagesetup event fixes things. But others breaks things. I suspect this has to do with priority. I don't understand the order of things here very well...

@ewinslow ewinslow force-pushed the views-b6844-master branch 2 times, most recently from 2faf1e3 to 5b025e1 Compare June 8, 2015 23:41
@ewinslow
Copy link
Contributor Author

ewinslow commented Jun 8, 2015

OK, figured out why menus weren't registering -- had change the pagesetup,system event guard logic a bit. It's fixed now. Just have to look into htmlawed and dev inspector and we should be golden

@ewinslow
Copy link
Contributor Author

ewinslow commented Jun 9, 2015

htmlawed seems to be working fine after my latest changes.

System cache is not going to work anymore for this, so I've removed it. Need to figure out a good way to turn some kind of caching back on so that building up this structure isn't so expensive on each engine boot... would it be horrible to pull this in before we've figured that out?

@mrclay
Copy link
Member

mrclay commented Jun 9, 2015

I'd prefer we didn't.

@mrclay
Copy link
Member

mrclay commented Jun 9, 2015

an overhaul of this size needs a lot more eyeballs on it and to make views even slower would quickly outweigh the benefits this brings.

@mrclay
Copy link
Member

mrclay commented Jun 9, 2015

Brainstorming: views with custom locations are likely to be rare; most views will be in core folder; most requests only use "default" viewtype (maybe separate services and caches); with cache on a lot of view operations should be noop (maybe we use a different views service?). Requiring individual view objects doesn't buy much IMO. Maybe as a nicer API when building up the definitions, but on most requests I don't think we'll want the overhead.

@mrclay
Copy link
Member

mrclay commented Jun 9, 2015

Being able to shard the cache by viewtype and maybe view name prefix I think could be a huge win. How often do we need css/js views, e.g.

@ewinslow
Copy link
Contributor Author

ewinslow commented Jun 9, 2015

I will keep at it.

@ewinslow
Copy link
Contributor Author

So the latest iteration of this that I'm almost done with will lazily instantiate View instances. That is, only views which are actually referenced in some way (to be rendered, extended, inspected, etc.) will be instantiated. I think this sufficiently addresses the perf concerns of generating all view instances on every request...

This also makes it possible to get path caching back, which is great, though I haven't gotten as far as thinking about how sharding will work.

@mrclay
Copy link
Member

mrclay commented Jun 12, 2015

Sounds great!

@ewinslow
Copy link
Contributor Author

OK, the code is in. I would guess I've spent north of 20 hours on this at this point... >_<. I apologize for the ginormousness of the change.

For my sanity please try to focus only on deal-breakers so I can just address the most important things. E.g. I'd prefer to avoid the busywork of breaking down this PR into smaller ones if it isn't completely required.

Note that caching and inspector are still broken, so those are known issues...

@mrclay
Copy link
Member

mrclay commented Jun 12, 2015

FYI default view counts (all approx): 860 total. 200 ^(js|css)/. 100 ^resources/. Maybe that will give me some caching ideas.

@ewinslow
Copy link
Contributor Author

~1000 views? I forgot how to count that low. (Seems like not enough to be worth any custom-designed memory optimizations we were discussing before).

Wonder how far we could get with a trivial caching solution courtesy of Stash.

}

/**
* Configure a fallback for this viewtype.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm lobbying for this feature to go away.

@mrclay
Copy link
Member

mrclay commented Jun 12, 2015

_elgg_services()->views->get() takes almost a second. Looking into why...

@mrclay
Copy link
Member

mrclay commented Jun 12, 2015

Elgg\Filesystem\GaufretteDirectory::getFiles() is super slow. It's digging through all of .git/*.

@mrclay
Copy link
Member

mrclay commented Jun 12, 2015

These seem to be blocking: #8467, #8468. I'll see what I can do here.

@mrclay
Copy link
Member

mrclay commented Jun 17, 2015

Closing in favor of #8509

@mrclay
Copy link
Member

mrclay commented Jun 17, 2015

One problem here is that extensions are rendered with all hooks and their own extension.

@ewinslow
Copy link
Contributor Author

They are not rendered with all hooks, so far as I can tell, but they are rendered with their own extensions, yes.

@ewinslow
Copy link
Contributor Author

ewinslow commented Jul 1, 2015

Sadly I will not be working on this further. Would have been nice to get this in but alas I wasted my time :(

@ewinslow ewinslow closed this Jul 1, 2015
@mrclay
Copy link
Member

mrclay commented Jul 1, 2015

Not a waste! Spurred a bunch of good changes and we've cleared the path for some flavor of refactoring in 2.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants