I'm developing a product for Plone, say foo.core. Besides that core product, there are also several related products. like foo.optional. These releated products may be available in the instance and if they are available they may be installed (in other words: I cannot assume the code is available or, if it is, should be used).
These related products may override settings made by foo.core (e.g. in a Property Sheet). This works fine, but if I reinstall foo.core, the default settings are back. What I'd want is to somehow automatically reinstall foo.optional when foo.core is reinstalled in the QuickInstaller.
The solutions I could come up with are:
When foo.optional is installed, it
registers itself with foo.core. The
latter, foo.core, will handle the
reinstallation of all registered
products when the core package is
reinstalled.
The foo.core package
triggers an event which other
packages, like foo.optional, can
listen for. An event handler will
then trigger the reinstall of
foo.optional.
Make sure that foo.core
doesn't overwrite any settings that
may have been customized later by
other products.
Perhaps there are more alternatives? What would be the 'Plonish' approach?
Edit: I know that using upgrade steps might be better than reinstalling the product. However IMHO the problem remains the same: the Generic Setup profile used for the upgrade step might have a setting that is modified in the Generic Setup profile for the foo.optional package.
So using upgrade steps makes my problem even harder: how should I determine whether the upgrade step of foo.core means foo.optional should be reinstalled/upgraded? (The assumption is still that foo.core in principle does not know about foo.optional.)
The solution to your problem is much easier than what you propose:
We do NOT reinstall products like we did in the past when the product is updated. Reinstalling a product will cause your generic setup profile to be reapplied which is why you get your settings overwritten.
Instead you now provide upgrade steps. For instance if you change your profile version from 2 to 3 then you would have:
<genericsetup:upgradeStep
title="Upgrade foo.core from revision 2 to 3"
description="Adds stuff"
source="2"
destination="3"
handler="foo.core.upgrades.two_to_three.addStuff"
sortkey="1"
profile="foo.core:default"
/>
Inside the upgrade step you can do what you like, even re-run individual import steps.
If your product upgrade does not involve changing the GS profile, do not increment the version in metadata.xml. In that case you obviously don't need an upgrade step either.
I suspect you are making things much harder on yourself by involving Plone's add-on installation story (which is complicated by "old" and "new" technologies living side by side). I would take a step back and think more about the plugin system you are trying to design/implement, and avoid including Plone until you absolutely have to [1].
You also might consider using entry points to implement at least a portion of the plugin system:
http://wiki.pylonshq.com/display/pylonscookbook/Using+Entry+Points+to+Write+Plugins
[1] Assuming Plone is a strict requirement and that you are building a content-management-driven application, else you should probably be using Django or Pyramid
Install/reinstall doesn't make sens in the context of an add-on. The vocabulary has been change to activate/unactivate but it is not again enough to understand the situation.
You have a 'setup' where you apply a configuration profile. Apply again and again a configuration profile doesn't make anything except broke existing configurations.
This is why every body will reply to this question by use upgrade step. We don't trigger profile on reinstall, we upgrade add-ons when the setup profile has some changes.
So if you are in a case where settings added by foo.core are changed by foo.optional you can do the following.
With the new plone.registry you can add a handler to the IRecord related events:
add
edit
remove
Consider the documentation:
http://pypi.python.org/pypi/plone.registry
I have done some code related to this where I want to rebuild css registry when some settings has been changed:
https://github.com/collective/collective.jqueryuithememanager/blob/master/collective/jqueryuithememanager/registry.py
Related
I have an Alfresco module that I would like to have do some cleanup when a new version of it is installed.
In the current situation, an older version of the module created a folder node with custom properties at the root of the repository. We've since decided to have multiple such nodes, and none of them at that location. I'd like to put into the next version of the module code that would run at Alfresco startup, check for the existence of the old node, copy its properties into the appropriate new nodes, and delete the old node.
Is such a thing possible? I've looked at the Bootstrap configuration file, but that appears to only allow one to add things to the repository, not modify or delete them.
My suggestion is that you write a patch. That is a class that implements
org.alfresco.repo.admin.patch.AbstractPatch
Then you can do pretty much anything you want on bootstrap (except executing searches against solr since it wont be available).
Add some spring configuration, take a look at the file patch-services-context.xml for inspiration.
Yes you can do that, probably you missed the correct place in the documentation about that:
If you open Import Strategy you'll find a section Per BootstrapView, you should be using something like REPLACE_EXISTING or UPDATE_EXISTING for your ACP packaged content (if you're using ACPs as your bootstrap importing strategy).
Here is a more detailed description of the UUID Bindings values.
Hope that helps.
You can use patches.
When alfresco server starts it applies patches and executes database updates etc.
Definition :
A patch is a piece of Java code that executes once when Alfresco
Content Services starts. Custom patches can be implemented.
Documentation Link
i'm about to setup a new server that will be dedicated for CC views i'm wondering if there is any way to move the existing views to the new server?
In theory, yes: you can unregister a view (cleartool untegister + cleartool rmtag -view), and register it again on the new server.
See:
"Moving a view to a host with the same architecture or to a NAS device"
"Moving a view to a host with a different architecture": it involves a cleartool reformatview -dump/-load in addition of the unregister/register steps.
(after the more general page "About moving ClearCase servers")
Honestly, in the past, I've just found it easier to throw away views and start over. We used a standard set of config specs that created task-specific branches per view. We worked with dynamic views (if you're working with snapshot views in clearcase, I think that you're using the wrong Version Control System), but had our developers checkin all of their changes (which by default would checkin against their feature branch), we'd then delete all of the views for the host being decommisioned, and had developers re-create their views normally (which would automatically start them up on the new server). We naturally abstracted away a lot of the customized config specs and setting up metadata for them so they only needed to run a simple command to continue.
We were not using UCM, however.
Now that I think about it, we just had a small handful of scripts that were used to do this work - basically wraps all of the dirty "view" details away from the developers (which honestly, they don't need to know about in general).
How can I able to find the usage of default tables available in drupal.
Is there any documentation available?
For example: there is a table called node. I need to know what is the usage of it and how it acts.
Any suggestions or answers will be helpful and grateful.
Your question is not very clear (the term "usage" is quite ambiguous), but you could install the Devel module. After setting it up it will show, for every page loaded (home page included), which SQL queries are run.
Every module can add tables to the database. A default Drupal install uses core modules, either required ones or those installed as dependencies of the default installation profile. These modules install their own tables.
Each module declares its tables in its implementation of hook_schema. The Schema module use the information from the implementations of this hook to provide a schema documentation.
Most of the time, you shouldn't directly access the database but use the API provided by the modules managing the data. Tables are usually considered private for their modules. New release of a module may change its schema in an incompatible way. Using API is much safer. Unfortunately, sometimes database access is the only option. In these cases, implementation of a data access layer between your code and the database is advised.
I have a sneaking suspicion that what I'm looking to do can be done more elegantly within Xcode 4 ... but then I've been wrong before. Here's the scoop:
I have an iOS app with the usual debug/release builds and regular, unit-test, and ui-test targets. Nothing unusual there. The app also calls out to a server. Nothing special there either. Except ...
Now I want to be able to build the app for four different server environments: Development, QA, UAT/Beta, and Production. In addition, each build must be able to co-exist on the same device, for developer builds or ad hoc distribution.
So let's see ... how might this pan out? Each app will need its own target identifier for starters. Perhaps detecting the kind of build could help target which server to use:
Debug builds target Development.
(Ad Hoc Distribution) Release builds target QA (... or UAT/Beta?).
(App Store Distribution) Release builds target Production.
As for those Target Identifiers (com.companyname.appname), I suppose I could use different Info.plist files for each build ... but that smells unwieldy (duplicate info). Perhaps it's the only way?
Bottom line: I'm uncertain of a) how to resolve the Ad Hoc vs. App Store Distribution cases, as well as b) the QA/UAT cases, as well as c) how to do this without messing up the (at least to me) more elegant setup Xcode 4 offers with those simple "Press Play" Debug/Release build ops.
Maybe I have to add new Schemes? Perhaps it's simply a matter of adding more Info.plist files ... or builds ... or configurations ... or targets ... or some mixture. Again, I'm trying to keep from duplicating a lot of info (only to change one or two settings) if I can help it. Debug/Release seems very clean as it is, and I want to make sure I change things along the proper axis. Measure twice, cut once, as they say.
Clues welcome/appreciated!
Here's what I ended up doing. Hopefully this is the most sensible way to go about it:
For now, I combined QA and UAT. (This may be split later on.)
I made three Info plists, one for Development (Debug), Beta/QA/UAT (Release), and Production (Release). Each of these has slightly different bundle display names, bundle identifiers, and bundle names, but is otherwise identical. (THIS is where the lion's share of duplicate info will be. Have to change things in all three - for instance, if I add a new font or URL type.)
I created a new configuration, Beta (based on the original Release/Production config), so now there's Dev, Beta, and Production configs as well.
In the Provisioning Portal, I set up App IDs using the previously declared bundle IDs, and generated new certs for Beta, Dev, and Production. (The existing app ID ends up being used for App Store releases.)
In the Build Settings, I used Conditional Settings to specify the appropriate Info plists and code signing identities.
I think this will do the trick! If there's a cleaner way, however, please weigh in. Thanks!
The challenge is to determine whether ASP.NET is enabled within IIS7 in a reliable and correct way.
Enabling/Disabling is done in this case by going into:
Server Manager ->
Roles ->
Web Server (IIS) ->
Remove Role Services ->
Remove ASP.NET
The natural place to determine this should be within the applicationHost.config file. However, with ASP.NET enabled or disabled, we still have the "ManagedEngine" module available, and we still have the isapi filter record in the tag.
The best I can find at the moment is to check if the <isapiCgiRestriction> tag includes the aspnet_isapi.dll, or that the ASPNET trace provider is available.
However these aren't detecting the presence of the ASP.NET config directly, just a side effect that could conceivably be reconfigured by the user.
I'd rather do this by examining the IIS configuration/setup rather than the OS itself, if possible, although enumerating the Roles & Services on the server might be acceptable if we can guarantee that this technique will always work whenever IIS7 is used.
Update
Thanks for the responses. Clarifying exactly what I want to do, I'm pulling settings from a variety of places in the server's configuration into a single (readonly) view to show what the user needs to have configured to allow the software to work.
One of the settings I need to bring in is this one:
The one highlighted in red.
I don't need to manipulate the setting, just reproduce it. I want to see whether the user checked the ASP.NET box when they added the IIS role to the server, as in this example they clearly didn't.
I'd like to do this by looking at something reliable in IIS rather than enumerating the role services because I don't want to add any platform specific dependencies on the check that I don't need. I don't know if it will ever be possible to install IIS7 on a server that doesn't have the Roles/Services infrastructure, but in preference, I'd rather not worry about it. I also have a load of libraries for scrubbing around IIS already.
However, I'm also having trouble finding out how to enumerate the Roles/Services at all, so if there's a solution that involves doing that, it would certainly be useful, and much better than checking the side effect of having the ASPNET trace provider lying around.
Unfortunately, if you don't check the ASP.NET button, you can still get the ManagedEngine module in the IIS applicationHost.config file, so it's not a reliable check. You can also have ASP.NET mapped as an isapi filter, so checking them isn't enough. These things are especially problematic in the case where ASP.NET was installed but has been removed.
It looks like the best solution would be to examine the Role Services. However, API information on this is looking pretty rare, hence the cry for help.
The absolute way to know if they checked that or not is to search the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Components
In there you should see two values set to 1, ASPNET and NetFxEnvironment and NetFxExtensibility. This registry key is the IIS Setup key that contains all the components that have been enabled in IIS.
Determining if asp.net is even an installed feature (prerequisite for enabling it) can be done through PowerShell, which implies there is .net api out there for it if you dig hard enough. The PowerShell methods:
Import-Module servermanager
Get-WindowsFeature web-asp-net
Which will return an object of type Microsoft.Windows.ServerManager.Commands.Feature. The installed property is boolean and indicates whether or not the feature is installed.
So do you want the easy way? Make a nice pretty .aspx page that displays as HTML with an error block in a div in a placeholder saying "You need to install ASP.NET" and have it change on ASP.NET being installed to instead say "ASP.NET is installed" and then just have the tool launch this webpage in the default browser after copying it to the directory identified in IIS as the *:80 site (or create the directory mapping in IIS programmatically by altering the XML and then removing it later)
May not be the most elegant but it does ensure that testing shows what features are truly installed versus what's in an XML file.
Because that will scream "do it the lazy ignorant way" I'll remind you that the only way for me to know in javascript what features I can use is to test them before I try to use them, or assume they're there and watch it blow up. My point is, it doesn't matter what gets reported in a file, it matters what you can actually use. Just because C:\Windows\Micrsoft.Net\Framework\v3.xxxxxxxx exists and has files doesn't mean the dll's are registered in the GAC, does it?