BC.Next Requests

Visitor Object Information:

Could this be expanded one day to have more information?

It would be great to be able to get more specific device information out through liquid and also detect through devicePixelRatio if a device is retina or not?

Why?

The goal would be to use, in combination of existing features to render image variations for retina display and mobile devices etc.

By Default or option to remove whitespace created by Liquid markup in rendered HTML. (This was an option in old liquid)

JSON Request 1:

You can do the following:

{module_booking,a, collection="eventCollection"}

<script type="text/javascript" id="event-json">{{eventCollection.items | json}}</script>

This renders the modules as json inline.

There is not the biggest use for this really unless you wanted to run some script on this json data inline.

It would be great to have access to a rendered json file for a module like events, web apps without taking two or three steps to create and fetch that information.

JSON Request 2:

json module:

Most external data sources are not just .json

An example would be:

http://api.rottentomatoes.com/api/public/v1.0/lists/movies/box_office.json?apikey=[your_ap i_key]&limit=1

Or

http://gdata.youtube.com/feeds/api/standardfeeds/most_popular?v=2&alt=json

None of these types of urls will work currently with the module_json are you guys able to get such URL constructs to work?

Being liquid rendered and if you have an api Key you need to include, these would be a little more secure. You can do this with javascript now which adds to load of a page. In Liquid this would be a pretty big feature enhancement and very useful.

Liquid Markup Includes:

Liquid supports includes, BC's current version does not yet.

Why is this needed?

Content holders are used by developers to create region content to edit for clients but also for code like footer or template sections like the head that they do not want the client to edit.

Having one thing with two separate functions creates problems, clients edit and break things they should never access or need to access and creates a number of problems for the sites operation and headaches for BC partners and developers

Includes would allow you to create a folder to put .tpl files in.

footer.tpl for example for footer sections and called with a liquid include in a template.

For a later update: Liquid in emails

Allowing liquid render within email and email marketing layouts to render before send.

That would break the restrictions they have put in place for a reason wouldn't it?

And apps are BC pages, so what works in BC sites will work in apps including liquid.

Cristinel said he had mapped out what to do for those cases rather going through this method. They are looking to increase security with apps further so I suspect that the limited hacks you can do with the parent (which is limited) will be locked down further, and they will provide alternate methods.

You are right though that liquid for both sites and apps will open the door for them to give us a bit more access to things, in saying that though it also can expose them to more things like denial of service attacks which Radu mentioned to me.

In terms of liquid you have {{globals.site}}

But I have not had any issues with my implementations for host access and document.referrer, the DOM for your app even presents the url, take a gander with your app pages in a window on their own to view what you can access.

It really would be great to get some BC feedback on these requests please guys.

We at Pretty for example would REALLY REALLY like to see includes.

Again, Content holders used by clients and developers - two sides of the coin using the same feature creates a variety of issues. Includes would be a great way to protect code chunks and allow developers to create them.

Content holders to this day render funny as well, so social things do not pick up right and things do not detect properly when used in the head.

Giving us includes from what I remember in the first liquid attempt by BC - The includes did not suffer those problems.

Site structure and what we do will (not may, or could, will) get Messy Lucian without includes.

As a developer I hope you can understand that, Already seeing things to messy and disorganised and a release of liquid that off the bat I think is a bad start in that regard. People like us at Pretty are going to try educate people in the right way of doing things, but if you can get includes in it would be good.

I went through the liquid documentation and integration in .net on the weekend in terms of the include stuff. BC is of course it's own beast but I did not think it was all that.

Do not forget you got .tpl you can run off so something like /_System/includes/myfile.tpl

And the include tag {%include"/_System/includes/myfile.tpl"%}

Would be what we are hoping for.

Shopping Cart:

{{this}} exposes a fair amount of the cart information but I currently do not see a collection for the products themselves.

If you guys have not got to this and when you do, could you please try and expose the product object in full.

The hope from us all is that with liquid we tap into the data and use it as we need to, if it exposes only the same data as tags it is a bit limiting still.

Things like showing or being able to use shipping weight information is really needed with the limitations of the shipping.

We at Pretty for example have looked at some options for custom shipping solutions which we can do enough of what we want, but when you need product weight to help form that solution or calculate total weight of the cart - We hit roadblocks.

If with liquid or now we were able to add data-weight=".... to product data and have a nice product collection loop for our cart with the data we want, we can then do more then shipping allows us until you guys improve shipping.

Basically allowing us to do something more until you guys do the ultimate updates, but that weight can be long so at least allowing us to do a bit more with more data is really important.

Shipping:

Shipping as a collection if possible please.

Could you add the toolbox to the product editor as well please. Anywhere it does not work in at the moment would be great.

Your limited to what you can do with products so being able to access insertion of modules etc would be helpful.

Markup Whitespace:

This was a thing that always annoyed me with coldfusion

Functional liquid tags  - {%%} create whitespace. Liquid has the following tag format:

{%-, -%}

Which prevents the whitespace in markup rendering. BC does not support it in this way but - {% -%}

As a request could you guys look to suppress the rendered white space by default, it may be easier?

Thank You

Devon, The editor will work just as it does with the current work. You can already go into your partner portal and define things.
IT is just a bit broke so will need fixing. BC already know about this.

In terms of turning things on and off - Already in the partner portal, this has not changed.

Just as you have things in the admin Cristinel.

For one of my apps, you may want the developers to have parts to set things up using the app for the client, but for them to be able to have option to set roles up so the client does not see those sections.

And then very similar for clients... There are lots of cases where you develop a custom solution for a bigger client who has several users but have more limited access and features (just to edit, or add content vs configuration) for  some of their staff who have access.

So you can modify the menu config with your app options, but you can not detect the user type when they are viewing the app.

{module_webformresults} - Liquify Please

Why?

Everyone has wanted to modify the formatting of this and run different things on the data. Exposing this to liquid will address all of this without having to change the module output or provide a layout by BC.

Campaign V3 API:

IS this coming?

Things we would like is the ability to more easily turn off and on customers email campaigns based on different conditions as well as have the current API in REST.

I am sure you guys have this down, I am just puttin ti down on paper as it were. Appreciate all the work done and how much still to do!

Doing an awesome job as a note, THANK YOU!.

There are some hacks right now to get a dynamic menu going in BC for a shop catalogue but it adds to many modules and not a great way. A few people have asked me about this in just the last week.

{module_cataloguelistdump} Renders a dump of the current catalogs in a catalog

{module_cataloguelistdump catalogId="-1"  collection="my_custom_collection_name" template=""}

Would render all catalogs from the root and expose them to a collection.

BUT this does not contain the children of the catalogs nor their ID's

{module_catalogueselect} Renders Catalogs in an option select output but can also be formed into a collection.

In the collection the data is the name, ID and the children of the catalogs but lacks the URL.

Catalogue list Dump module therefore should contain all the child items of each cataloge so you can properly create a custom dynamic menu as you need to.

Page information in globals...

page

• title: text Title of the page.
• name: text Name of the page.
• url: url
  Url of the page.

Also, It would be great if you guys could implement the Liquid URL paramater fetching, this would be really powerful. I know you can use the module_url but you would have to assign that to a value. I can see the liquid URL paramater features on shopify for example allows more direct use.

You mean like we are now Rob?

At Pretty we have already pitched this with triggers, being able to form requests with others and have interval operational triggers. I think there is a big pitch thread on it here as well that I wrote.