How about this idea? Limits should be a part of CDS too.

[smolinari]

For instance (and I am not sure it is in the right place).

public function testRepeatObjectWithLimit() {
    $template = '<template name="">
            <ul><li>TEST1</li></ul>
    </template>';
    //This time we have a limit of 2, so only two iterations should be presented
    $cds = 'ul li {repeat: data(list); iterations: 2; content: iteration(id)}';
    $data = new stdclass;
    $data->list = [];
    $one = new stdclass;        
    $one->id = 'One';
    $data->list[] = $one;
    $two = new stdclass;        
    $two->id = 'Two';
    $data->list[] = $two;
    $three = new stdclass;      
    $three->id = 'Three';
    $data->list[] = $three;

    $template = new \CDS\Builder($template, $cds, $data);

    $this->assertEquals('<ul><li>One</li><li>Two</li>' ,$template->output()); 
}

Would that (or something similar) be feasible?

Is the data retrieval also being controlled over the CDS? Or is the template system "given" the data? I'd like to see it retrieve, like it should be.

Scott

[TRPB]

Completely agree with this, and the impementation. Perhaps we need to be able to do offsets as well?

Perhaps the way page ranges are specified for printers?

Default: Indefinite:

repeat: data(list) 1 *;

Range 5-7

repeat: data(list) 5 7;

First 5:

repeat: data(list) 1 5;

Do we also need to do sorting here? How would that work?

edit: I suppose we could do:

#id {repeat: data(list); sort: iteration(date), iteration(author.name);

[smolinari]

Not sure about ranges or sorts. I can't come up with a use case directly and I am not sure a designer would be concerned about ranges or sorting. They would be concerned about the number of times an html element should be rendered despite the amount of data capable of being returned. Like 4 album thumbnails wide. Or 5 top poster rows down, etc. Or, maybe there should be a limit and a max. Max is the designer's ground, and the limit is for userland.

So, theoretically, the values should be externally settable. Like

$cds = 'ul li {repeat: data(list) limit max; content: iteration(id)}';

and limit and max be bound to a variable in the application. I am thinking along the lines of web components and them being dynamic, like how many images to show in this web component introduction. We'd also have a way to say, "you can have up to 25 pictures (max) in the slider, but you can also reduce that to any number you'd like (limit).

https://css-tricks.com/modular-future-web-components/

Scott

[TRPB]

Yes, i think you're right.

That said, the designer might be concerned with "Top 5 rated" or "Newest 10".

Consider a .cds which listed movies (imdb style) and the two pages "Highest rated" and "Newest". The only real difference between the two lists is the heading (which we can populate using h1 {content: "Newest"; } and the data.

So in this scenario, using the same template we either need:

Two versions of the data selecting logic or two versions of the CDS that sorts/limits the data. From a practical perspective, fetching all the data and then filtering it in the CDS is ridiculous. You'd have to load all the movies on IMDB, pass them into the template and then sort/limit them in the CDS which is ridiculous so I agree with that.

Where design does come into play with sorting, however, is that the designer might want a random banner image from the ones available, or to include the banners in a random order. So perhaps we just need a shuffle option.

I think you're right about ranges, it means the designer needs to know quite a lot about the nature of the data in order to be useful.

[smolinari]

Consider a .cds which listed movies (imdb style) and the two pages "Highest rated" and "Newest".

This is me just thinking out loud with a use case of two lists showing the same content using the same template and cds, but possibly for two different pages.

The designer only knows he has to display a list of movies. He knows going over a maximum number of items would cause the page to break, so he sets a max. Actually, now that I think about it more, max needs to be first. Limit should be optional, since that is userland.

So the cds for the movie list template could be something like

.movielist ul li {repeat: imdb(list) 10;};
.movie ul li {content: movie(image_url, title, description, rating);}

So again, the designer only knows he has a possible list of movies to work with no matter what is asked for, the designer sets a maximum of 10 iterations, because any more would break the design or what ever other reason there might be. That is all she should have control over. The fact there is a "top 5" or a "newest 10" is part of the model and not really display logic. I'd say, the same goes for pagination too.

In the example I changed "iteration" to describe the objects held in the list (collection?) or rather the object found in each iteration. This could be broken down further for arrays within the objects.

.actorlist ul li {repeat: movie.actors(list) 5 };
.actor ul li {content: actor(name, profile_pic_url)};

When I see that, all I can think is, how cool is that! :smile:

Edit: and think about this too. A base CDS could be produced automatically by the model. This would tell the designer what data is available. She must only add the extra behavior. Yes.

Scott

[smolinari]

I just found what looks like a fairly popular JS framework called mithril and started reading the docs and it hit me. CDSs are sort of a model view interface. They are a bridge between the view and the model and they need to be compiled to VMs in both PHP and JS (and even server side JS for the node freaks at some point), for CDSs to work.

https://lhorie.github.io/mithril/getting-started.html

Check out the view part in those docs. You've got to be kidding me! The HTML page is written purely in JS and people accept that? Oh brother.

CDSs for the win!

I mean, the CDS puts everything in its rightful place. The front end developer can concentrate on JS. The back end developer can concentrate on PHP (or JS). And the designer can truly concentrate on HTML. Then everyone meets at the CDS.

I think what we need to get rolling properly is a complete catalog of behaviors required to build model views in any conceivable way. I will start it in another issue. Oh, this is going to be so cool and I can't even start to express how excited I am.

Scott

[TRPB]

I've just added support for repeat: data(foo) 3 to limit to 3. However, it needs tweaking as it doesn't support repeat data(foo) data(max) yet.

[TRPB]

repeat: data(list) data(max); is now also supported. I'll close this for now and the code is now structured in a better way that allows multiple values for properties separated by spaces, so offsets could also be easily implemented in the future.