I see there are a number of classes available in the package freemarker.template.utility. Is there a way for these to be exposed in the data model so that they can be used inside a template?
It seems like that might be what they are for but I can't figure out how to access them from my templates.
Thanks!
You can create an instance of the desired object, and drop it into the data-model like anything else. Or, you can set said objects as Configuration-level "shared variables", via Configuration.setSharedVariable.
Related
Lets say I'm building a laravel package, which has hierarchy like this:
PackageContainerClass > *PackageClass* > SomePackageClassMethod()
I want to make PackageClass swappable by a class from main App.
I know I could create a publishable config/package_config.php where the user could override PackageClass location and then use it for creating PackageClass object in the package. But I have quite a few classes to be 'swapped', and dont really feel that its the right approach. What's the best approach for this, is there any Laravel magic I dont know about?
I'm new to Thymeleaf / Spring and have just introduced a message_en.properties file. I see the benefits of using it, however, it's a bit of a pain to populate it.
I have a form, I've just added several inputs, I know need to add each of these as keys in the message file. Is there a way of doing this on the fly for me?
To automatically populate the message properties, you may have to consider using a scaffolding solution like jHipster or something similar.
refer http://jhipster.github.io
I have created a document-based app that uses Core Data. I created the mac version first, and now that it's working properly, I am moving on to create an iOS version of it.
I just can't get my head around how to maximize code reuse between the iOS/mac versions, with respect to the Core data bit, since they don't use the same classes.
My document class that handles saving and such is a subclass of NSPersistentDocument. My intention is that a well-designed model class should work in both environments, especially since I don't do all that much fancy stuff with regards to Core data.
Now, since NSPersistentDocument isn't available in iOS, I hit a wall. I tried to get around this by using #if TARGET_OS_MAC and TARGET_OS_IPHONE and in that manner make it a subclass of UIManagedDocument in the iOS version. That obviously would have been convenient, but I can't seem to make it work like that. And it's really looks quite messy, since there are a lot of other stuff that has to be conditionalized as well.
I also tried building the classes atop of NSDocument/UIDocument instead, implementing the Core data hooks myself, but it also looks quite messy, leaving me thinking it's not the right way to go.
The question:
To me, it seems like a good idea to reuse the same document class between the iOS/mac versions, but maybe I'm being naive.
What's the best way to do this?
Should I forget about the code sharing and create a separate document class for the iOS version that emulates all the methods present in the mac version?
Am I right that the code you're wanting to share is model-related? I suggest refactoring that code to a separate object, which both an NSDocument and UIDocument contain (as rickster suggested above).
I use a DocumentRoot Core Data entity with its own NSManagedObject subclass, but if there are no properties you want to manage using Core Data, you can just subclass NSObject.
This may sound strange, but NSDocument and UIDocument are actually controller classes. (To be specific, they're part of the model-controller.) Their jobs are to load the model, set up windows, and save the model. If you need to provide an interface for higher-level access to model objects, it could be in a document root or model helper class instead.
Similarly NSPersistentDocument's job is to configure the managed object context and the persistent store and handle loading and saving. It doesn't necessarily need to provide a complete interface for accessing the model.
(Bringing this over from my comment.)
In general, the situation where you have two classes which must inherit from different superclasses but which also want to share a lot of code is composition. Put the shared code in a separate class; your NSDocument and UIDocument subclasses can each keep an instance of that class, and message it whenever they need to invoke that shared code. (Though as #noa mentions, you might want to consider whether all of that code belongs in your document class to begin with.)
Of course, then you might end up writing a bunch of methods that read like:
- (id)doSomething {
return [sharedController doSomething]
}
That can get to be a pain... so you might want to look into Objective-C's message forwarding system.
is there a way to get the prefix name of a managed package in apex?
I have a SOSL query but the app is in a developer org and in a managed package, if I have a way to get the package name, it would be great, because I don't have to hard code it.
Thanks.
The only way to do this, AFAIK, is to use the Metadata API. You can call describeMetadata() and then evaluate the organizationNamespace (String) value returned in describeMetadataResult.
From within Apex you could do a less elegant try/catch approach with dynamic SOQL/DML, at least to determine if something you suspect is there is actually there. Though this won't tell you what namespace prefix actually IS there like the Metadata API will.
Lacey is correct that you don't need the prefix, though name ambiguity can become a problem. So for example, if you have a custom object Expense__c and have installed an accounting package which includes ACCT__Expense__c, you definitely want to explicitly include the ACCT__ prefix if intending to access the managed package object as opposed to your own.
The UserInfo.isCurrentUserLicensed('nsPrefix') will throw a TypeException if the namespace passed in is not a valid namespace of an installed package (or managed package you're developing). I think this is the closest you're going to get without the metadata API.
Using this guide I have created a static library (let's call it AppCore) that can be shared between the Mac OS X and iOS versions of one app. This static library uses Core Data and the point of it is to share the model part and schema versioning between different implementations.
I created a NSPersistentDocument based project that will depend on this AppCore. In this project I added a reference to the .xcdatamodel file. Then I created a simple table view with add/remove buttons to edit an array of one entity type with the assisted "new core data entity" item. This created an instance of NSArrayController and the required bindings for the add/remove behaviour.
Now, everything seems to work fine when I'm using the default class for the Core Data entities (NSManagedObject) and I'm able to add new rows using the +/- buttons. However, when I change the entity implementation class to a custom one, I'm getting an error
Failed to create new object
This seems to come from the NSArrayController and it seems to be unable to instantiate the required entity. I can, however, create one in the NSPersistentDocument subclass by:
[NSEntityDescription insertNewObjectForEntityForName:#"SomeEntity" inManagedObjectContext:[self managedObjectContext]]
What confuses me is why the instance of NSArrayController can't. If I understand correctly, the array controller is instructed to create an entity, not class and my guess is that the entities are created with the help of NSEntityDescription class. I could implement my own version of the array controller's add: but then again, it might be that here something is fundamentally wrong. I haven't touched the init:s and the custom entity class implementation is simply for convenience, to access the attributes directly.
I have tried changing the base SDK on the AppCore but without effect. Currently it uses the iOS version but I'm not sure how it should be. This is another question but if unrelated, I might ask it here on a separate question.
So, to summarize, why can't the NSArrayController create an instance of this entity?
Thanks in advance.
Update
This works if I add the SomeEntity class from the AppCore to the dependent project as a reference. This is not the most usable way since modifications to the AppCore has to be propagated to the dependatnt projects also.
Bingo. I missed the "-ObjC" flag for the dependant project's "other linker flags". Now everything works like a charm.