Open xat opened 12 years ago
@kat I like the overall idea. It'd probably be easiest to implement it by allowing a processor to be specified in the object you pass to Response.create
. When do you think the processor should be called? Would it be called each time there's a breakpoint crossover or only once? Should the return of the processor be used to override the content? There already is a crossover event (see the readme) which would enable you to do some of that already.
Response.create({prop: 'width'}).crossover(function() {
// do stuff each time viewport crosses width breakpoints
}, 'width');
First of all thanks for the response and for making my text more readable :-)
I see Processors as independed of Response.create
.
Just an example why I think they should be independed:
<div
<!--
default behavour like it is already implemented
Content is set directly within the attribute
We could also call it the 'default processor'
-->
data-min-width-481="Some Content"
<!--
on this breakpoint the 'template'-Processor gets called
instead of the default processor
The 'template'-Processor decides which content should be shown
-->
data-min-width-980-template="#mytemplate"
<!--
The 'ajax'-Processor gets called.. content is loaded async
-->
data-min-width-1024-ajax="ajax-snippet.html"
>
default content
</div>
As you see, if we dont bind Response.create
directly to an processor
we are totally free to choose which processor to use on a ceratain
breakpoint crossover within the markup.
The processor would always be called on an breakpoint crossover which is postfixed with name of the processor, not just once.
No, I thought of the content being set inside the processor instead of being returned.
Something like context.$el.html( 'new value' );
inside the processor. In this way
we could also deal with async processors like the following example:
Response.addProcessor('ajax', function(args, context) {
$.get(args, function(response) {
context.$el.html(response);
});
});
If I understand the readme correctly the already existing crossover event informs me if a breakpoint has been "crossoverd" but I'm not able to influence which content to load, or am I wrong?
Simon
Internally it still needs to be tied to a breakpoint set so that it knows what breakpoints to listen for. I have a pretty good idea about how to go about adding the capabilty. It seems like it would be most flexible to have it so that the function is called at the time of the update on a per element basis and overrides the default update action. The function would get passed info about what breakpoint was crossed etc.
I've just looked through the reponse.js docs. It looks very promising and we consider using it in upcoming projects. However, I have a suggestion how the library could be even more flexible, here is a mockup of the basic idea:
The API gets a new method like
addProcessor([name], [function])
In the Markup you can then trigger this Processor with a syntax like:
The Processor 'myprocessor' gets triggerd and "some argument" passed in through 'args' and 'context' provides information about 'min-with', '481' and the element itself ($el). Instead of a pure string argument we could also think of an object as argument:
data-min-width-481-myprocessor="{param1:'my argument',param2:'my argument2'}"
The benefit of this is that we get great flexibility. One real-world example how this could be used: Instead of putting all content inside attributes, pull the content from templates:
Content could also be loaded with ajax requests and so on...
Just some thoughts :-)