-
Notifications
You must be signed in to change notification settings - Fork 16
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
Caching #9
Comments
This looks great! Let me take a look it in more depth this weekend. (You're correct that Fortitude is not an employer-sponsored project, and I'm quite scrupulous about not working on it on my employer’s time or premises.) I'd love to have a clean, simple caching mechanism built in that integrates well with various things (Rails’ cache most particularly) without actually requiring any of them. Vaguely related:
|
That all sounds 👍, and yes, I saw the staticization stuff, it's a great idea, but I'm not sure we'd be able to use it in too many places. |
I spent some time today wrapping my head around this and how it interacts with Rails’ caching stuff, and I really like it — extremely simple. I plan to write it (among other things, it should use an |
Awesome! I'd love to start contributing code myself, but my first goal is still to find an application of ours to port over to Fortitude. |
Completely understood! By all means, let me know if there’s anything I can help with. I’m always excited to have more people using it. |
Hey, @ageweke, just came across One question: we have something of a shop standard (for classes in general) that methods that are mutually ignorant of object state get put into an require_relative 'index_content' # declares Views::Welcome::Index::Content class
require 'menu_factory'
# Class encapsulating all page-specific view code for `welcome/index`.
class Views::Welcome::Index < Views::Base
# Methods neither dependent on nor affecting instance state.
module Internals
def self.menu_factory
MenuFactory.new
.add_item(href: '#', caption: 'Home')
.add_separator
.add_item(href: '#', caption: 'Sign up')
.add_item(href: '#', caption: 'Sign in')
end
end
private_constant :Internals
def content
widget Views::Page, page_content: Content, nav_menu: Internals.menu_factory
end
end # class Views::Welcome::Index (For those wondering, we do this to silence Reek complaints about methods that don't affect instance state, that simply declaring How does Fortitude see this class? Will it treat the And why do I feel like a fxxxing n00b asking so many questions instead of diving in and getting even less sleep? Sorry, guys… I've been "live-blogging" a couple of exploratory apps (actually, variations on the same app); anybody with any interest and/or advice should be able to get a pretty fair handle on my thought processes there. |
@jdickey — first off, don't worry about feeling like a n00b! Fortitude still has effectively no documentation (which I'm working on), and so it's just impressive that folks are able to use it at all. Feel free to ask away…anything at all. I'm more than happy to answer any questions! A brief introduction to def footer
div {
ul {
li { a("Facebook", :href => "http://www.facebook.com/…") }
li { a("Twitter", :href => "http://www.twitter.com/…") }
…
}
…
}
end Because Fortitude works like it does, every single time any page is rendered, it's going to invoke every method — This is inefficient — it's the exact same string every time, so why are we doing all this work? If you add
In essence, once it's run the first time, that method now becomes: def footer
rawtext "<div><ul><li><a href="http://www.facebook.com/…">Facebook</a></li><li><a href="http://www.twitter.com/…">Twitter</a></li>…"
end This runs much faster than the method above, because it's a single string concatenation, rather than a bunch of nested methods with blocks. One of the reasons that I've placed documenting (An interesting point: most other templating engines are fastest when cranking out large chunks of static HTML — because, to them, it's just giant strings to be concatenated directly onto the output — and slowest when doing lots of interpolation, My guess is that for most applications, this difference is going to be in the noise until they've spent lots of time optimizing elsewhere. So I'd encourage folks to ignore Coming back to your example: without seeing the code for Is it the latter? If so, it's an interesting question you pose. I can definitely see the value in the convention you describe (and I love it when Rubyists think like this), but also don't see an immediate solution. I'll think more on it, though, if that's what you're trying to do. Is it? Cheers, |
@ageweke Thanks for the wondrously informative reply! I've a much clearer understanding of For the record, the code in Fortitude is already turning into Great Stuff for us; documentation would be an Amazingly Good Thing,, of course, and in a few weeks I'm going to have to sit down and figure out how to put several of these widgets (the standard-page-layout widgets discussed here among them) into Gems we can decouple maintenance of from the apps that use them. I put a week into trying to wrap my head around that while you were enjoying your hike and gave up; hopefully I'll have better success next time. Thanks again! |
I’m gonna close this for now — it’d be great to fold discussion in under PR #54. :) |
I wrote this caching module for erector-rails4, which adds all of the neat cache_digests stuff to widgets. What's even cooler about using cache_digests in Erector is that because your needs are explicit, you can calculate the
cache_key
for a widget without having to manually specify the objects it depends on.Is this something you'd be interested in implementing in fortitude? Anything about the implementation that you'd want to change?
The text was updated successfully, but these errors were encountered: