How to manually write code to show products in two different currencies, toggled by buttons - shopify

We have tried using some of the most popular Shopify Apps for this, and they work fine, but we have no way of controlling the exchange rate, on which basis the currencies are converted. This is very important for us, so we decided to find a way to code it manually.
I'm new to Shopify, but I have a sense of what I'll need to do within Liquid to effect the change. I'll need to change a Liquid variable somehow based on the selected currency and then recalculate it based on the value of that variable.
I am aware that you cannot trigger Liquid from Javascript, as they don't run concurrently, which makes the entire logic fall apart in a sense, or maybe I'm thinking about it the wrong way.
How do I need to approach this?
Any help would be appreciated.

Related

Optaplanner: How to calculate score delta for move

I'm using Optaplanner to automatically solve school timetables. After a timetable has been solved the user will manually change some lessons and will get feedback on how this affects the score via the following call:
scoreManager.updateScore(timetable);
This call takes some 200ms and will, I assume, do a complete evaluation. Im trying to optimize this and want to only pass in a Move object so that Optaplanner only has to recalculate the delta, like:
scoreManager.updateScore(previousTimetable,changeMove);
Is there a way to do this?
There really is no way how to do just a single move. You don't do moves - the solver does moves. You can only make external problem changes to the solution. You should look into the ProblemChange interface and its use in the SolverManager.
However, the problem change will likely reset the entire working solution anyway. And after the external change is done, you're not guaranteed that the solution will still make sense. (What if it breaks hard constraints now?) You simply need to expect and account for the fact that, after users submit their changes, the solver will need to run; possibly even for a prolonged period of time.

Should a backend api store layout information?

I need to create a system to store and serve information about survey questions. Given a variety of questions, field types and field arrangments, I need to serve the data needed by the front end to display the fields.
One of my big concerns is layout information. I'm not sure all the ways the fields can be arranged. At a minimum, I need to support things like two text fields appearing on 1 line, with a third on the next line. Or 6 multiple choice answers arranged in 2 columns of 3 rows.
Is it appropriate to store this layout information in my database, and to serve it with the question/field data? I think these are my 3 options. Any thoughts on these options would be very helpful, or suggestions for other things to consider:
I could store indicators that the question uses a column layout, and give each field hints as to what row/column it is in.
I could store something like CSS or mustache templates to define the layout.
I could leave this entirely to the front end. I could return the survey data and expect the front end to handle any layout concerns
The general answer/advice i would give is no. If you put any layout information in the database you will make it very hard to build new functionality, extend your product offering in the future, support multiple front ends (mobile, progressive web app, main website) and perform redesigns in the future.
I would go with option C. Leave it to the front end. You can easily store the 'type' of question which may map to a template in the front end maybe, this will allow the different front ends to render that type of template as the design needs. And will allow you to easily evolve the design in the future, the last thing you want if you desire to do a redesign is to need DB update scripts to try and 'fix' css and display data.
Obviously i lack the full picture of what you are trying to achieve, the road map of your product and your future ideas, but i honestly cant think of a scenario where storing css in the DB would be a good idea.
I hope you find this useful, I would be keen to hear how you decide to progress with this.

Big Commerce, Top\Featured\New Products on category page

Hi there working with bigcommerce Im looking to get the following style of break down on each category page
Essentially making a category version of;
%%Panel.HomeFeaturedProducts%%
%%Panel.SideTopSellers%%
%%Panel.HomeNewProducts%%
Ive gone ahead and attempted this however they seem to be pulling in from global values, and there dose not seem to me much option to break these down or limit the category, has anyone done this previously and if so how?
developerscott is correct in those panels not offering contextually unique data. I'd recommend looking into Unbxd. It has a 30 day trial so you can either investigate their programmatic solution or use it in place of making your own.

Edit a small SQL rowset using forms in Django

I'm interested in displaying 1-5 model instances using forms on a page using a grid similar to something one would find in a desktop database application. I understand I would need to use multiple forms or formsets but an additional requirement is that I'd prefer it to be in more of a grid format with each model's fields being display in columns with common field labels on the y-axis.
I should have the ability to edit multiple columns (so in effect, model instances) at the same time and then commit either the single column (model instance) or commit all. I'd also like to be able to highlight the changed cells that have changed to give visual feedback to the user that there are pending changes.
Sorry for the rather long list of requirements and I'm aware this probably requires a few different technologies/techniques to achieve. I'm throwing this out there because I'm asking this kind community for guidance on what components/technologies I should look at. If luck would have it, there would be some jQuery component that can handle this for me almost out of the box. If not, some guidance on achieving the editing of multiple model instances would be of help.
I will also need to build in versioning in case the data displayed on the view page is stale and to prevent overwriting a newer commit. I'd probably achieve the latter using a versioning field in the table that will perform the check and handle it accordingly.
Also, Flask and Django are both options for the engine and WTForms look to be promising at least at first look.
Thanks
There is no such ready to use solution in Django. Just create your custom form that handles as many instances as you want and do anything that you want, or extend formset.

Dynamic Methods/Rules

I need to create a product configurator, but according to the requirements, literally every product has a set of rules to validate it. The rules refer to the quantity of underlying components the configuration is made of.
At the moment the way this is being handled is just storing the "formula" string in the db, and since the UI is in Excel, then when you call a configuration, it comes with the rules as well and you just append a "=" in front of it. Thus, the final product works when quantities or components change.
So I've seen a few similar type of questions being asked, and the answer always seemed to be UJS, however, this is stored in the app itself, correct? The challenge for me is to create a way I can replicate these rules depending on the product, and different products are beeing added all the time, changed, etc, so keeping it in the app to redeploy each time you want to change something seems a bit extreme!
Can anyone think of a good solution? Help!
These are business rules so they'll need to be stored somewhere server-side (they could be mirrored in client-side code but storing them there exclusively is highly inadvisable ;). They could be represented as code, or configuration files, or in a database.
As you suggested, modeling frequently changing rules in source code makes your app brittle. I think the best storage option is your database.
If you need to implement a client-side behavior on a per-product basis, you could use AJAX to send a product ID out to a service which returns a configuration "package" to your (dumb) client.
Would that work? Sounds good to me, anyway. ;)