module_webapps and liquid layouts

I have asked similar questions here:

Liquid render questions

With the implementation of liquid there are several ways of doing things, but unclear yet what the preferred or what final methods will work or not work in BC's implementation of things yet.

You should read more on collections though, they are the means to do liquid layout code for that item below the item itself without having to go into creating or using a new layout for it.

Same issue. Follow.

All modules are designed to work with the template="" collection="capture_data" syntax, including the webapps module.

I've tried this on a website and seems to work. Can you please send the exact code-snippet you're using?

Also, are you sending the filter="all" parameter? if you don't the module does not render properly:

{ module_webapps id="22762" filter="all" template="" collection="my_custom_collection_name" }

To check Lucian, filter="all" will indeed be all items?

filter="all" is the syntax equivalent of the "a" parameter of the webapps module.

{ module_webapps,3120,a } is equivalent to { module_webapps id="3120" filter="all" }

What I mean is all will be all and not the 800? odd limit before pagination?

I apologize for asking a question I haven't researched yet, but in reading through these posts, I began wondering if BC is indeed requiring the filter to be stated in order for it to work. Aren't there default settings? Shouldn't filter="all" be assumed if no filter is specified? I hope that's already the case, and I am just misunderstanding, because good tag design would attempt to minimize the amount of markup required for success.

No Adam, You need it. It is still running of the BC tech, like with the API when you declare the limit of web app items your requesting.

Not good. Oh well, we can't have everything at once. It is a usability issue for designers, though, and it would go a long way toward making tags easier to use.

They split up things, nothing has changed functionality wise for the module and liquid is just a new better way of tapping into the data. They not really done anything new yet like they said.

I not really got answers to those types of questions, the engineers have been quite cagey on anything to do with things like that. Is filter all actually "all" or is it still the limit for example, what about the months of passing on info about what data is there but no tag/output for it, are we seeing access to that info, liquid does not seem to open up to as much info as I was expecting it to... We not seen any BC updates during a very long period now, there seems to be no one even ticking over small bugs or bugs that are causing features to be broken.

It is if Lucian and Radu are the only developers on BC now and all they are doing and have been for the last x months is trying to get liquid working. In the alpha server I not seen the new cache engine working yet for example. The editor has ticked over to near same level functionality as current one.

Excited about new stuff but also very very concerned too.

I agree with Adam that requiring the filter to be specifically stated is not a very good user experience.  I understand this is just a carryover from the past but this would be a good time to correct that mistake since everyone has to learn how to use the new syntax anyway. And like Liam, I am curious if this has something to do with the web app item limitations.

Dayrl,

That is part of the system now, I do not have any issue with it. You need to say what your limits are for your output for performance. If you just always said all and then just cut the results down etc after the fact - Bad coding. If you wanted to set your own pagination or not and have limited results you can do so.

The thing I am curious about as on the Alpha stuff at the moment it keeps changing is what was announced at the start in terms of no pagination etc. Does  "All" mean all. And if you say "20" there is no info on how you would create your pagination though liquid or collection.

- Do you have a new parameter in the module to specify a pagination layout? Do you do that in your list layout template? How does it work with Collections? What is the syntax to know your on last page?? All those sorts of questions have not been answered. Not sure if BC has got to that side of things yet. But they are important to know.

I don't think you understand what Daryl was saying, Liam, with regard to specifying the filter.

The idea is that there should be default values for all the parameters. The default value for filter should be "all". We definitely should not have to specify that every time. Building defaults into modules is a no duh move, and can't be that difficult.

I do, I disagree with that and from a BC standpoint, everyone using that and loading "All" by default because most people just do the default is a bad idea. Average increased load on the server through the all requests. And then from our standpoint loading by default then handling.

Yeah, Do not think that is a good idea, and that will have come across the BC desk for their end and having that as a requirement to continue that through modules into liquid is fine by me.

Isn't there a default, only load 10, then paginate, whereby negating the sever load issue argument?

In any case, the majority of the time (read: default) people are saying {module_webapps,123456,a} anyway. Or {module_webapps, appname Filter="all"} (or however the liquid markup goes).

Those that need a specific item, or random item, or items in a category etc then specify the filter there and then, to filer away from the detaul "All".

I don't see an issue with Filter="all" as a default, personally.

Agreed Stephen.

The argument against it is really, really poor.

All is not all as well as a note.

Collections etc will likely run same as the API does.

I do not think the argument is poor based on what BC is actually doing and why Adam. You talked to them on this?

The other important note is that this is not a full replacement of the old module system. They will still work. And when BC update the admin it will output in this new format. So will work as it does now.

Any thought of always show all etc is simply not a good idea as a default and as a developer it is bad practise.

If your building big sites, limit to the amounts you need, that is part of code development 101 stuff, Literally no point in any front end optimisation if your just going to be hammering the server itself all the time.

With liquid, doing it badly will actually have such impact. BC may be able to handle the load, but it does not mean your site performance wont suffer.

You also got to remember you have the collection ability with modules, including web apps.

Liam, I'm not sure why you're saying that defaulting filter="all" is "doing it badly" when all we're implying is automatically set filter="all" as a default, instead of people always having to type in filter="all".

If your argument is such that filter="all" is bad for the server then BC needs to ensure that a) no one can ever do filter="all" or b) fix the rendering of liquid in such a way that filter="all" is not an issue.

Regardless of your reasons surrounding the server load, which I'm not disputing, making filter="all" just seems like a no brainer considering that I'm forever mostly going to be using filter="all" anyway.

Default All as it is will be 500 ish, seems to vary though from my tests, not sure if BC have load baring in there.

With JSON output and liquid and collections you either need to be able to get all data or set the limits and run collections and have both pagination options and liquid code option to continue fetching results.

So if BC as they need to set "ALL" to be all and that is the default and someone just dumps 1k+ web app items all the time etc that will be an incredible load on the system. Those limits they put in and being so low are for those.

It has not anything really to do with the liquid rendering but more on the load baring aspect of the server. Web apps are on the top plan at a cost for a reason and BC keep saying they can not offer on lesser plans for that reason.

And as I mentioned when the admin is updated to run on named paramaters then it will be as it is now, and have an option and when you click it I think it just does 10 by default etc.

Anyone going in with just blind output factor work with liquid, especially with their collection use, loops etc are going to get themselves in a world of hurt and doing it the wrong way (which you can EASILy do) will not see the perfomance gains they could get. I have already done collections with loops and some complex things which have completly caused the page to just endless load and spaz out.

Ok I realize I'm late replying to this thread but Liam, I don't think you're understanding what we're saying because nothing you're saying refutes it.  Look, what we're saying is that whatever the default is, you should not have to specifically state it to make the web app itself work.  I don't care if the default filter is 3 items for filter="All".  You should not have to specifically state filter="All" for the web app to work.  You keep on talking about load on the servers but what we're talking about has absolutely nothing to do with load.  The load on the server is determined by what the limits are for filter="all", not whether or not you have to state it in the markup.  I'm not sure why you aren't understanding that.

Again, the default filter="all" could be only 3 web app items and my point is still the same.  To get those 3 web app items to show should absolutely NOT require me to add a filter="all" to the markup. 

In other words, if you just write {module_webapps, id="mywebappname"}, I'm okay if the output results in 500 items, 10 items, 1 item, or whatever BC wants filter="all" to represent.  But it should never be ZERO items like what we currently have. Otherwise the API fails the intuitive test.

And on a sidenote, there's also some inconsistency regarding using plural vs singular for this module.  In my opinion, it should have been {module_webapp} because you're only referencing 1 web app.  For displaying a photo gallery, we don't use {module_photogalleries}, we use {module_photogallery}. Same for blogs and forums.  I think the webapp and breadcrumb modules are the only ones wrongly using the plural form.  One of the hallmarks of a great API or framework is consistency if at all possible because with that consistency comes intuitiveness.

Hey Daryl,

It came up in the unConference, With the way things work now and tapping into the information in the options you need to, this is not basic application stuff, it is a lot more complicated and there still needs to be server management of that data access so it does not kill BC.

Just as current modules do in the editor, you will be able to do the same and the toolbox will eventually output in the new way just same.

You will need to loop through sets of data till you reach the total return results if they exceed the maximum single fetch limit.

BC basically re-iterated that point at Max, so this wont be changing

Liam - Daryl is saying that these two lines should produce the same output:

{module_webapps id="Areas of Law" filter="all" }

{module_webapps id="Areas of Law"}

The only sane default for filter is all, not the none it has now.

Sidenote: the filter parameter has no control over the number of items displayed; use resultsPerPage for that.

I know what you guys are saying Robert, But you need it to exist.