After the latest update for Glass, my code is essentially broken because of the deprecation of the Card.getText() method. What would be a painless alternative to this method?
.toString is of no use because of the Object return type.
The getters were deprecated because CardBuilder is not designed to be used as the data model for your application; it should only be used to plug in data and get views back out. If you need to retain information that you can query later, you should just design your own objects to contain that information (and then you might add a simple method/factory that creates CardBuilders from those objects).
Related
for a project, I am trying to create a web-app that, among other things, allows training of machine learning agents using python libraries such as Dedupe or TensorFlow. In cases such as Dedupe, I need to provide an interface for active learning, which I currently realize through jquery based ajax calls to a view that takes and sends the necessary training data.
The problem is that I need this agent object to stay alive throughout multiple view calls and be accessible by each individual call. I have tried realizing this via the built-in cache system using Memcached, but the serialization does not seem to keep all the info intact, and while I am technically able to restore the object from the cache, this appears to break the training algorithm.
Essentially, I want to keep the object alive within the application itself (rather than an external memory store) and be able to access it from another view, but I am at a bit of a loss of how to realize this.
If someone knows the proper technique to achieve this, I would be very grateful.
Thanks in advance!
To follow up with this question, I have since realized that the behavior shown seemed to have been an effect of trying to use the result of a method call from the object loaded from cache directly in the return properties of a view. Specifically, my code looked as follows:
#model is the object loaded from cache
#this returns the wrong object (same object as on an earlier call)
return JsonResponse({"pairs": model.uncertain_pairs()})
and was changed to the following
#model is the object loaded from cache
#this returns the correct object (calls and returns the model.uncertain_pairs() method properly)
uncertain = model.uncertain_pairs()
return JsonResponse({"pairs": uncertain})
I am unsure if this specifically happens due to an implementation from Dedupe or Django side or due to Python, but this has undoubtedly fixed the issue.
To return back to the question, Django does seem to be able to properly (de-)serialize objects and their properties in cache, as long as the cache is set up properly (see Apparent bug storing large keys in django memcached which I also had to deal with)
I am using APEX 20.2.0.00.20. apex.region(region_static_id).widget() method should return a jQuery object according to the documentation. I am trying to figure out how to know what the object's properties and methods are, especially when they are not mentioned in the documentation. I tried running apex.region(calendar_region_static_id).widget() to return the object and inspect what properties and methods it has but I got S.fn.init [div#CAL_calendar.fc.ui-widget.fc-ltr, prevObject: S.fn.init(1)] 0: div#CAL_calendar.fc.ui-widget.fc-ltr length: 1 prevObject: S.fn.init [document] __proto__: Object(0)
I did not get the object. I do not know what s.fn.init or the rest of the returned code is?!
I see code like apex.region("calendar_static_id").widget().fullCalendar("getView"), so I assumed I should have gotten the jQuery object which has the "fullCalendar" method and more when I ran apex.region(calendar_region_static_id).widget(), but I have not.
Is this not the right way to inspect a jQuery object's properties and methods?
APEX integrates the FullCalendar widget, but it doesn't duplicate its documentation. Have a look here for a list of the FullCalendar methods and options.
In general, most (interactive) APEX regions are implemented as jQuery UI widgets. That means you can use them like this:
$('selector').widgetName('methodName'); //invokes said method
$('selector').widgetName('methodName', 'param1'); //invokes said method with a parameter
$('selector').widgetName('option', 'optionName'); //gets a specific option
$('selector').widgetName('option', 'optionName', 'newVal'); //sets a specific option
What's more, you can inspect all available options by running:
$('selector').widgetName('option');
And even have a look at the internal object, see all methods, public and otherwise, via:
$('selector').widgetName('instance');
Moreover, via its region interface, APEX offers an even easier way to reach those methods and options, even without having to know a region's widgetName:
// this
$('widgetSelector', 'staticId').widgetName('methodName');
// is equivalent to
apex.region('staticId').widget().widgetName('methodName');
// is quivalent to
apex.region('staticId').call('methodName');
The last way is the shortest and doesn't require knowing the real widget's id or widget name.
All of this helps when dealing with regular APEX widgets, such as the Interactive Grid.
apex.region('emp').call('instance'); //inspects all methods
apex.region('emp').call('option'); //inspects all options
This however does not work on the FullCalendar region, for reasons that are beyond me. It should help you navigate all other APEX regions, but for the FullCalendar you'll have to resort to their API docs.
Hope this helps a bit.
In Glimmer.js, what is the best way to reset a tracked property to an initial value without using the constructor?
Note: Cannot use the constructor because it is only called once on initial page render and never called again on subsequent page clicks.
There are two parts to this answer, but the common theme between them is that they emphasize switching from an imperative style (explicitly setting values in a lifecycle hook) to a declarative style (using true one-way data flow and/or using decorators to clearly indicate where you’re doing some kind of transformation of local state based on arguments).
Are you sure you need to do that? A lot of times people think they do and they should actually just restructure their data flow. For example, much of the time in Ember Classic, people reached for a pattern of "forking" data using hooks like didInsertElement or didReceiveAttrs. In Glimmer components (whether in Ember Octane or in standalone Glimmer.js), it's idiomatic instead to simply manage your updates in the owner of the data: really doing data-down-actions-up.
Occasionally, it does actually make sense to create local copies of tracked data in a component—for example, when you want to have a clean separation between data coming from your API and the way you handle data in a form (because user interfaces are API boundaries!). In those scenarios, the #localCopy and #trackedReset decorators from tracked-toolbox are great solutions.
#localCopy does roughly what its name suggests. It creates a local copy of data passed in via arguments, which you can change locally via actions, but which also switches back to the argument if the argument value changes.
#trackedReset creates some local state which resets when an argument updates. Unlike #localCopy, the state is not a copy of the argument, it just needs to reset when the argument updates.
With either of these approaches, you end up with a much more “declarative” data flow than in the old Ember Classic approach: “forking” the data is done via decorators (approach 2), and much of the time you don’t end up forking it at all because you just push the changes back up to the owner of the original data (1).
I am currently in the process of writing a custom DataProvider. Using the Intergrate External Data documentation.
I've managed to show the external data in the Sitecore back end. However whenever I try to view the data in the items I created, I am getting an error
Null ids are not allowed. <br> Parameter name: displayName
There seems to be precious little on the subject on how to create a custom DataProvider on the Sitecore Developer Network.
The example on their website seems to only show how to import a SINGLE item into a static database. However I am simply trying to merge some items into the hierarchy and I can't find any useful documentation.
It seems that one of your methods that should return an ID doesn't. It might be GetChildIds and/or GetParentId.
Nick Wesselman wrote a good article about it gathering all the information including an example on the Marketplace. I think that is your best start. You can read it here.
Turns out I needed to include at the very least, the Fields->Section->Template in the GetParent method. To be on the safe side I included the Fields/Sections/Templates into my implementations of
GetChildIDs
GetItemDefinition
GetParentID
It wasn't obvious that this was the case, since I had in fact implemented the GetTemplates method correctly, and I had expected that should be enough.
I've found myself unsatisfied with Django's ability to render JSON data. If I use built in serializes then database foreign key relationships are not included in the data (only the keys). Also, it seems to be impossible to include custom data in the json feed that isn't part of the model being serialized.
As a test I implemented a template that rendered some JSON for the resultset of a particular model. I was able to include/exclude whatever parts of the model I wanted and was able to include custom data as well.
The test seemed to work well and wasn't slower than the recommended serialization methods.
Are there any pitfalls to this using this method of serialization?
While it's hard to say definitively whether this method has any pitfalls, it's the method we use in production as you control everything that is serialized, even if the underlying model is changed. We've been running a high traffic application in for almost two years using this method.
Hope this helps.
One problem might be escaping metacharacters like ". Django's template system automatically escapes dangerous characters, but it's set up to do that for HTML. You should look up exactly what the template escaping does, and compare that to what's dangerous in JSON. Otherwise, you could cause XSS problems.
You could think about constructing a data structure of dicts and lists, and then running a JSON serializer on that, rather than directly on your database model.
I don't understand why you see the choice as being either 'use Django serializers' or 'write JSON in templates'. The middle way, which to my mind is much more robust and fits your use case well, is to build up your data as Python lists/dictionaries and then simply use simplejson.dumps() to convert it to a JSON string.
We use this method to get custom JSON format consumed by datatables.net
It was the easiest method we find to accomplish this task and it looks very fine with no problems so far.
You can find details here: http://datatables.net/development/server-side/django
So far, generating JSON from templates, we've run into the need to escape newlines. Looking at doing simplejson.dumps() next.