I’m trying to customize the look of an instance of a GeoNode Project and I can’t find the base templates. The templates folder has only this file.
I have installed according to the official tutorial.
How can I access the base templates from GeoNode, in a GeoNode Project instance?
When starting with a geonode-project not all geonode templates appear.
Also, GeoNode behaves quite differently in versions <4 and >=4. Customizing in versions <4 will be more appropriate for those who are more familiar with Django and HTML templating, while in versions >=4 requires some more detailed knowledge in css/js and node-js.
Here is some material that may be useful for creating a geonode-project and customizing the interface in GeoNode 3.3.1.
Related
I'm maintaining a library (MyLib) published on npm that is a vuejs plugin. When I started this library, vuejs was at major version 2.x.x. vuejs now has a new major version 3.x.x that changed how plugins work.
Both 2.x.x and 3.x.x versions of vuejs are supported and will be for a while longer. I want my plugin library (currently version 5.x.x) to be available and supported for both.
Options I've seen or considered so far:
Have 5.x.x as the last version that supports vuejs#2 and 6.x.x and above for vuejs#3.
Easy enough
Doesn't allow me to release a new version with breaking changes that supports vuejs#2 ever if I follow semver rules.
Create a version 6.x.x of my library that supports both versions of vuejs.
Potentially possible, depending on the specifics.
Makes my library bloated because it needs to support both versions of vuejs and have (flaky) runtime version detection to choose the right code path.
Publish a separate library (e.g. MyLib-v2) that supports vuejs#3. Can possibly use a scoped package, but that would force users of 5.x.x of my library to change their dependency name with very poor discoverability.
Not sure how to manage this in a single repo. Monorepo?
Clunky, higher overhead
Is there a better way, or at least a not-awful way of managing publishing my library in this seemingly common scenario?
Use vue-demi. It lets you publish for both vue2 and vue3 in the same project. When using vue2, you have will access to the composition api as well.
https://github.com/vueuse/vue-demi
From the read me:
Vue Demi (half in French) is a developing utility
allows you to write Universal Vue Libraries for Vue 2 & 3
I was checking the official documentation from Microsoft and it states that the FeatureGate attribute can be used to control whether a whole controller class or a specific action is enabled. I've installed the Microsoft.Azure.AppConfiguration.AspNetCore 4.2.1 and even 4.3.0-preview but I can't find it:
using Microsoft.FeatureManagement.Mvc;//doesn't recognize .Mvc it recognizes up to Microsoft.FeatureManagement
[FeatureGate(MyFeatureFlags.FeatureA)]//doesn't recognize FeatureGate either
FeatureGateAttribute is an API for ASP.NET Core applications. It's not included in the base feature management package (Microsoft.FeatureManagement). You need to install the Microsoft.FeatureManagement.AspNetCore package.
Instructions can be found at
https://learn.microsoft.com/en-us/azure/azure-app-configuration/quickstart-feature-flag-aspnet-core?tabs=core5x#connect-to-an-app-configuration-store
WHere can I get a XD version of dojo source like the one hosted on google? What I want to do is to host dojo source from my local CDN, and my custom dojo module in my web application. Is this a good practice? or I might as well just include the dojo source in my web app, and run the custom build?
Thanks,
You can build an xd version of dojo from the source code
Here are instructions on how to do it:
http://dojotoolkit.org/reference-guide/1.7/quickstart/custom-builds.html
See the section on "doing xdomain builds"
In our organization (a large one), we do have a CDN version of dojo deployed on internal CDN mainly since some of our webapps are not allowed to access extranet (firewall issues).
For performance, though, a custom build gives biggest boost since it is customized to the modules you need/use - once the custom build is done, you only need to ship a single compressed js output file and a small number of supporting files
When doing your custom build, you can use the xdDojoPath and loader=xdomain if you wish to use cross domain dojo to load your optimized js - see http://osdir.com/ml/cometd-users/2011-08/msg00050.html for some notes on this
Also see related SO question: Dojo on a CDN vs own install
The good news is that with Dojo 1.7+ and the new loader, you don't have to do anything special for a cross domain build (good answer above from #Vijay Agrawal, but I think that reference guide link may need some updating for 1.7) Just write your code to the new AMD format, use asynch:true, run the build tools to create layers, and deploy them on any server. AMD makes use of callbacks and many of the tricks the old Dojo xd builder used to employ, but in a much simpler way.
To support older code, there is a legacy cross domain mode mentioned in the loader docs.
Lotus Notes 8.5.3 uses dojo 1.5.1. However I want to use dojo 1.6/1.7 library in my NSF database. How can I do it? I tried to use the technique suggested by Keith Strickland in his blog but no luck.
I need to include the dojo library in NSF database and not on server.
The reason I want to do this so as to use the advanced Dojo Mobile libraries (from dojo 1.6/1.7) in my XPages.
UPDATE: I even posted this question on XPages forum some time back but no replies.
The Domino 8.5.3 server uses Dojo 1.6.1 for XPages. You should see this if you view the HTML source of a test application.
As an example, I see this in one of my applications:
"/xsp/.ibmxspres/dojoroot-1.6.1/dojo/dojo.js"
If you are going to create apps using Dojo Mobile then take a look at the Extension Library and the latest Upgrade Pack 1 for Domino 8.5.3. Both includes XPages Mobile controls.
Per's correct that the Dojo plugin that is loaded by default is 1.6.1 (the ".1" is because it includes IBM-specific code and this means it differentiates it from anything a developer has added in).
The files in the js folder on the server / client are 1.5.1 and this is needed for iNotes.
You can change the Dojo version in the xsp.properties by setting xsp.client.script.dojo.version in Package Explorer. Incidentally UP1 offers a nice visual editor for the xsp.properties file.
However, currently if you change this setting you need to uncheck "Use runtime optimized javaScript and CSS resources" or it will still use the plugin. I noticed this too late for anything to be done before the Gold release.
If you add 1.7 files to the server and include the IBM folder from 1.5.1 it may work. AFAIK there's no way to get the IBM folder from the plugin code.
See my blog post for more details: http://www.intec.co.uk/domino-8-5-3-greater-power-over-dojo-thanks-ibm-for-your-work/
I'm looking to find something like Torry but instead of being Delphi centric, it should be Lazarus centric.
I'm aware of the Source Forge Project Code and Component Repository but I'm looking for something with more span and a bit more searching features.
There is this page in the Lazarus wiki which probably has most of Lazarus components (it includes some components not found in CCR). Its pretty well searchable. There are also the forums and the mailing list where components are announced (and usually are mentioned in the above wiki page).
Lazarus isn't as popular as Delphi or other solutions, so its not that easy to find stuff for it :-/. Although porting components from Delphi isn't a very hard process - many components available for Lazarus were originally Delphi components.
Here is a component web site :
http://lazarus-components.org
I have seen that we can create lazarus repositories, but there is poor doc about that.
Recent versions of Lazarus IDE have an Online Package Manager function.
IDE Menu: Package > Online Package Manager.
This open a window with a pretty good list of packages that that be downloaded and installed with a couple of clicks.
I use lazarus BigIDE from http://www.pilotlogic.com/sitejoom/index.php/codetyphon
full LCL from more source