I've made a custom resource and I want to load it as a default in an export variable so I've tried this:
extends Node2D
export(Resource) var custom_res=CUSTOM_RESOURCE.new()
and my custom resource script as such:
extends Resource
class_name CUSTOM_RESOURCE
export var data=10
but for some reason it doesn't seem to show up within the editor:
am I doing something wrong?
shouldn't the editor display the custom resource as default whenever the scene is instanced like this?:
Running the initialization in the editor
That initialization is not running in the editor, only when the game starts.
You know the solution is tool:
tool
extends Node2D
export(Resource) var custom_res=CUSTOM_RESOURCE.new()
And all that comes with it. For people finding this form search, be aware of Engine.editor_hint.
Setting the default value
Turns out the reason we need the initializer to run is because what we are setting (CUSTOM_RESOURCE.new()) is not constant.
We can confirm that with a simple constant, for example:
export var x := 5
In that case the initializer didn't run in the editor per-se. Instead Godot set the constant was set as the default value when it parsed the script. And that is what we see in the Inspector.
So we want a constant value of our custom resource. Well, preload is a constant expression (preload is a keyword not a method). And yes, it is resolved while parsing. And yes, Godot will set it as default value, despite it not being a primitive type. Thus we can preload a resource file and use that, for example:
export var custom_res:Resource = preload("res://new_resource.tres")
Which, of course, requires that we have resource file to preload. We can create it from the context menu on the FileSystem by selecting "New Resource…", then picking our custom resource class, and a file name to save it.
Notice this differs from running the initializer in the editor in that:
It does not require tool and all that comes with that.
With tool, the default value remains (null). So you will see the arrow to reset the value in the editor, and clicking it erases the value of the property.
Your custom resource object will be the default value. So you won't see the arrow to reset the value right away. And if you modify it, resetting it the value gives you your resource object back.
Gotcha: Everywhere you preload the same resource file, you get the same resource object. Modifying it will modify it everywhere. Even across different scenes.
Related
I've been researching but couldn't find a clear answer. As far as I know using global variables in nextjs isn't considered best practice but what is wrong with assigning locale, regions, navigation etc as global variable instead of prop drilling it to every component?
pages/_app.jsx
global.locale = useRouter().locale
global.regions = regions
global.navigation = navigation
...
useRouter is a hook which would trigger a rerender in case the locale changes. When you assign it to a global variable changes to the locale will not have an effect on what React is rendering.
Usually, the locale doesn't change but in theory a link can tell the router to switch the locale without reloading the page from the server.
Instead of prop drilling (pretty cumbersome) you can call the hook in every component where the locale is needed (like links). Assigning the variable to an observable MobX store would be similar to having a global variable and not require prop drilling or repeated use of the same hook. There is also a HOC called withRouter.
In the Nautilus System Browser (Pharo 6) there's a right-click command to Add package... as well as Add class... and even Add protocol..., but I can't find anywhere a way to Add method....
Where is that command?
In Pharo, adding a method is not as explicit as the other elements. To add a new method:
Select the protocol for the method, and you should see a template in the editor pane:
messageSelectorAndArgumentNames
"comment stating purpose of message"
| temporary variable names |
statements
Edit this template to make a new method,
Save (Right-click Accept) it using Ctrl-S.
In fact, any time you change a method's definition (e.g., messageSelectorAndArgumentNames) and save it in the editor (Right-click Accept or Ctrl-S), it will create a new method.
For more details, see the section 1.3 of Developing a simple counter document (emphasis is mine):
Create a method
Now let us create the accessor methods for the instance variable count. Start
by selecting the class Counter in a browser, and make sure the you are editing the instance side of the class (i.e., we define methods that will be sent to
instances) by deselecting the Class side radio button.
Create a new protocol by bringing the menu of methods protocol list. Select
the newly created protocol. Then in the bottom pane, the edit field displays
a method template laying out the default structure of a method. As a general
hint, double click at the end of or beginning of the text and start typing your
method. Replace the template with the following method definition:
count
"return the current value of the value instance variable"
^ count
This defines a method called count, taking no arguments, having a method
comment and returning the instance variable count. Then choose accept in
the menu to compile the method.
I need an alternate for the EditorTemplate of an Enumerator Field that's used when the Field has a particular name (PublishingMethod).
Based on the docs, I created a view with the pattern [ShapeType__FieldName] in the same folder as the original shape:
This is not working and still uses the original. I've thought of changing the Editor method in the Driver, but I think that defeats the purpose of alternates, which is that Orchard automatically detects the correct shape as I understand from the docs:
The Orchard framework automatically creates many alternates that you can use in your application. However, you can create templates for these alternate shapes.
Note: I can't use the Shape Tracing module, it never worked even with a clean Orchard install.
The editors in Orchard work different to how Display works. I guess it is so you get a MVC-style experience. Basically, the actual shape returned is of type EditorTemplate, which then binds your model and prefix then renders a partial view with the template name you gave it. What this means is alternates wont work as expected, or as the docs state. The alternates for your field name are actually added to the EditorTemplate shape. So what you can do is add a view called EditorTemplate-PublishingMethod.cshtml with contents like:
#{
var m = (Orchard.Fields.Fields.EnumerationField)Model.Model;
}
#Html.Partial("PublishingMethodEditor", m, new ViewDataDictionary {
TemplateInfo = new TemplateInfo { HtmlFieldPrefix = Model.Prefix }
})
Then add another view called PublishingMethodEditor.cshtml with the overrides you want for your editor. All these views should go in the root of your Views folder.
Another approach would be to implement the IShapeTableProvider interface and adjust the TemplateName property on a certain condition but, meh, that requires code...
Edit 1
If you have that field name on other content types that you don't want to override you can use the override EditorTemplate-ContentTypeName-PublishingMethod.cshtml
I would like to pass data such as navigation items or languages supported to the portal_normal.vm file so that it gets displayed on the portal.
I don't have a clue about how to do it. I've seen that in velocity files the data is passed in variables as follows:
<title>$the_title - $company_name</title>
I would like to do the same for navigation items and other data in my portal but I have no clue how.
Liferay's themes have a file called init.vm - this initializes quite a bit of the data. If you don't find it in your theme, it will be loaded from the _styled or _unstyled theme that you can find within the portal (or the portal source).
You can also look at the Java side of the equation: There's a class called VelocityVariablesImpl, this initializes "the other" variables in the context.
In addition, you can have a file named init_custom.vm in your custom theme, where you can add more initialization. This file is meant to be empty in default themes, but as it's included and evaluated, you can add your custom variables and initialize them in here.
I have a MainView which has an associated MainViewModel in my WPF application, assigned via its contructor.
App > start up uri > MainWindow.xaml
public MainWindow()
{
InitializeComponent();
var viewModel = new MainViewModel();
DataContext = viewModel;
}
My MainView holds as many as four nested views or child views who are hidden and displayed based upon the button that has been clicked on the MainView. So we toggling the visibility property vi a binding which gets updated via command bindings assigned to each button on the MainView.
Each nested View does not have an associated ViewModel, all bindings found on child views find their information in the MainViewModel. So binding system ends waling up the UI tree of the app to find out that the parent 'MainView' has an associated ViewModel.
So overall there is 'ONE' -> ViewModel. This seems to work fine and but as expected this VM has gotten to big and needs re-factoring. It holds information that contextually it should not. But this is a proof concept application. So i decided to keep it simple and make sure it was do-able.
PROBLEM:
When i tried assigning a empty view with an empty view model I noticed binding errors in the output window and as expected weird and broken behaviour. Which makes no sense ... Is there a more clear and concise way of letting WPF know how to handle any bindings it finds in a nested view control? I thought if each view's constructor assigned itself a corresponding VM as shown above, then it should work as this logically makes sense. Unfortunately all buttons on the MainView stop working when the corresponding view it is designated to switch on and hide the others has an associated ViewModel. On some buttons it works and the others it does not? This is really weird?
As mentioned in my answer above, the problem was that WPF binding system was struggling to to resolve bindings at run time. The main view has its associated view model instantiated and assigned via the Main View contructor and this pattern is repeated for all nested views that the MainView also houses.
By default, I tend to use the implied binding syntax which means that without explicitly specifiying a source the binding system will try to resolve the name you supply in the binding. So it's all implied and nothing is explicitly set!
Upgrading each nested view to have its own view model makes this auto discovery/resolution of bindings go a little crazy and I have not explicitly told the binding system where to find the property I am looking for hence the output window binding errors.
This leads to unexpected behaviour as the output window was telling that it was trying to resolve binding expressions in nested views --> viewmodels. When in actual fact that VM it is looking in, IS EMPTY!
So clearly the binding system is good when you do not explicitly set a source property inside the binding syntax. It is clever enough to find things on its own. In my case it needed some extra help, as it was unsure as to where to find things.
SOLUTION:
Remove the constructor declaration for the MainViewModel in the MainView constructor.
Scope in an xmlns for ViewModels namesapce into your MainView.xaml
Create a window resource inside the MainView .xaml
Give the resource a key.
Upgrade all your bindings in the MainView xaml file to include source property.
Give the source property a static resource binding that points to your ViewModel key value set up in step 4.
Only do step 6 for bindings who refer to the ViewModel that is associate with the MainView.
All nested views are to be left alone, they should handle their own bindingds in their own xaml files. The MainView simply instantiates them and places them onto the UI. For me this was the case, I did not have any more bindings concerning my nested views. All Bindings that lived on the MainView.xaml file referred to data in the MainViewModel.cs. This makes alot easier when viewing your problem.
For some reason the editor was being awkward so I chose to omit any sample code but the steps above are descriptive enough to follow the steps that I took. Above is what worked for me.
ANOTHER WAY OF SUMMING UP THIS PROBLEM
Most books teach the shorter binding syntax
What happens when more than one data context is available?
How is the binding system supposed to know how to resolve your short hand binding expressions.