I'm starting to get into dnn 5 module programming (using dnn for the very first time).
The issue is i can't seem to be able to use my new module. i programm it, then apparently y install it, but when i try to add it to a pane in the page, the page loads, but no module appears. i try to install it again, but a tag reads "it's allready installed".
i've followed instructions for doing this, for dnn 4, but there seems to be something different in the procedure to follow.
Here are the instructions i "adapted" to dnn 5:
http://blog.dmbcllc.com/2008/05/29/dotnetnuke-modules-registering-your-module/
I hope some one can tell me what i am doing wrong, or more likely, what should i change in the instructions followed.
Try this and if it fails, please post the module definition. (.dnn file)
I did my first dnn 5 module last week - I created the new module definition directly from the dnn host admin area and didn't add any controls. Once I added the controls, my module still didn't appear because all my controls had a "key" defined.
You need to make sure that 1 control in your module definition is added "without" a key - this is the default view (ascx) that will load for you.
Related
I'm trying to use Unity's excellent new CrossPlatformValidator
(Such as seen ...
http://docs.unity3d.com/Manual/UnityIAPValidatingReceipts.html or
https://docs.google.com/document/d/1dJzeoGPeUIUetvFCulsvRz1TwRNOcJzwTDVf23gk8Rg)
But it can't be found! Naturally I am ...
using UnityEngine;
using UnityEngine.Purchasing;
I also tried different stripping and .Net levels. Nothing.
Anyone have a clue about this?
The type or namespace name `CrossPlatformValidator' could not be found. Are you missing a using directive or an assembly reference?
Stuff like this is usually found at UnityEngine.Experimental but it wasn't there when I looked so I guess it is not a new feature.
1. You can find it by going to Windows -> Services. Sign in on the Window displayed, usually on the right.
2. Create a Project ID on that Window.
3. Click on In-APP Purchasing. It is checked to OFF, click on it then click Enable.
Note: You must Sign in to be able to Enable it and you must Enable it before you can use it from Script.
Finally, the completely undocumented namespace is:
using UnityEngine.Purchasing.Security;
note that one can see this in the generated "tangle" files, for example, if one forgets it. :/
Mono Dev can often help you find things.
Right click on unresolved class -> Resolve
Screenshot of resolve function in Mono Dev.:
I have been studying ATG for about 4 months and now I am facing a problem: even going through the documentation I can't find any document that can clearly explain how I can create a new empty store.
I know that I need to have my database users and schemas, the application server scripts (I'm using weblogic) and the module in Eclipse. But I can't find anywhere how to create a new store, implement it from the beginning and see the result in the browser.
There is no such document for ATG. You either need to start from the Commerce Reference Store and customise that (in versions prior to ATG 11 would would strongly suggest not to use the CRS as your basis for a new site) or you can look at what the CRS executes for the runAssembler command, remove the CRS specific modules from that and then create, and include your own modules for the Storefront and your source code.
There is no empty store you can install and run. You have to build one. Or you can install CRS, which is not empty, but it is relatively straightforward to install and can be customized.
The documentation to follow:
http://docs.oracle.com/cd/E52191_02/CRS.11-1/ATGCRSInstall/ATGCRSInstall.pdf
https://www.sparkred.com/blog/installing-oracle-commerce-11-1-with-commerce-reference-store/
*
I've started investigating alternatives to my project and a few questions came out that I couldn't answer by myself.
The problem is: I want to create a web page able to access multiple Magento instances installed in the same server. Currently, I have one Magento instance per client and this project will access several Magneto instances to export reports from each one (for example).
The alternatives I thought til this moment are:
Have another Magento instance, create a new module within it that changes its 'database target' before triggering operations/queries;
Questions until this moment:
Can I 'change the database target' of a Magento instance?
How can I access data from a Magento instance without appeal to SOAP/REST?
I want to re-use some components (grids, tabs, forms..) from Magento, that's why I'm not considering an independent project (Zend, for instance) that can access this code from another projects. Does it make sense?
Any other idea?
==Edited==
Thanks by the tips and sorry by my ignorance. The comments let me believe that I'm able to execute something like this:
// File myScript.php
require '/home/DOMAIN1/app/Mage.php';
Mage::app('default');
// get some products from DOMAIN1
require '/home/DOMAIN2/app/Mage.php';
Mage::app('default');
// get some products from DOMAIN2
Is it right? Can I execute require twice (and override things from first require)?
==Edited2==
I'm still trying to connect to several Magento instances from a single third party file. Is there any tip? I'm facing several/different errors at this moment.
The only thing I know is that I can still rely on SOAP to get the information I need, but this will be expensive.
Thanks!
The easiest way would be to include Mage.php from each shop instance. You would need to use namespaces or some other trickery to be able to load more then one.
Or if that doesn't work - make your own API in a separate file to get what you want from one shop, and combine the results in the PHP-file that calls the API.
Here's a sample on how to use Magento functionality outside of Magento:
require 'app/Mage.php';
if (!Mage::isInstalled()) {
echo "Application is not installed yet, please complete install wizard first.";
exit;
}
Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);
// your custom code here, for example, get the product model..
$productModel = Mage::getModel('catalog/product');
I have a D2006 app in which the DPR file has had numerous edits (yes, I know - you shouldn't mess with the DPR file) to accommodate such things as a splash screen, preventing a second instance of the app being started, handling of command line options that need to be processed before any forms are created, etc.
One day, I noticed that the auto-create forms list in the project options is empty - but the DPR file still has the code in there to create some of the forms.
If I try to restore all the forms that should be auto-created from the dialog, it complains Error - Call to Application->CreateForm is missing or incorrect and doesn't do anything.
How can I restore this connection - apart from rebuilding the DPR from scratch?
is it safe to manually add the CreateForm calls?
are there any documented rules as to what you can do in the DPR file?
I have a suspicion that try..except and if..else clauses in the DPR upset Delphi. Will moving as many functions as possible to a separate unit and calling them be helpful?
I haven't really seen any documented rules as to what you can do in the DPR file, because I guess there are no strict rules.
The problem begins when you create a "Forms" application. (No problems with console or non-GUI applications I've noticed).
The IDE will automatically change the DPR any time you add a new Form or a DataModule to it, by assuming you want to auto-create them.
This can mess up your DPR, if it has a lot of code/compiler-directives/if-blocks/try-catch blocks etc...
So I'll tell you what my rules are, and in a short line:
Keep it as simple as you can.
My DPR contains only a call to some init code and auto creates the main form only:
MyAppInit; // in AppInit unit
Application.Initialize;
Application.CreateForm(TMainForm, MainForm);
Application.Run;
However in the uses section I add (or keep what the IDE added) all the forms my application uses (and also application related units) - this is useful when I want to view->forms or view-units.
In-fact when I add a new form to the application, the first thing I do is go the DPR and remove the line:
Application.CreateForm(TMyNewForm, MyNewForm);
NOTE (EDIT): The IDE can be configured to NOT auto create forms (No Application.CreateForm entry will be created in the DPR). In older version of Delphi this option is under: Tools/Environment Options/Preferences -> Auto create forms. In newer versions: Tools/Options/VCL Designer/Module creation options -> Auto create forms & data modules.
At run-time, I create all my forms dynamically when I need them, and destroy them when they no longer needed. DataModules/Splash (etc...) are created on the MainForm.OnCreate event.
This method has worked for me nicely for the past few years maintaining a large scale DB application. This will probably not cover all cases, but it worked fine for my needs.
P.S: "Is it safe to manually add the CreateForm calls" - Yes. But think twice if you really need them to be auto-create by the application.
IMHO You don't really need that AutoCreate forms from Delphi, but maybe in the casual test project.
And the dpr is just another source code file, where you're meant to write code to make things happen (or prevent it to happen), so don't worry if you lost that sincronization, which IMHO is buggy if can't read your pascal code to work properly.
If you still want to create some forms from the DPR, add the Application.CreateForm or TMyForm.Create calls manually to the file, AFAIK there's no rules against doing it that way.
Since Delphi owns the .DPR, I put my startup logic into a separate unit for each project.
That works really well, only very few entries need to be in the .DPR.
Since that unit controls the Application.CreateForm logic too, the IDE has an empty list for that: I'm fine with that.
The only things left in the .DPR are:
the big uses that indicates which modules are part of your project
a call to Main in the startup logic unit
I need to use ZendAMF on a symfony project and I'm currently working on integrating the two.
I have a frontend app with two modules, one of which is 'gateway' - the AMF gateway. In my frontend app config, I have the following in the configure function:
// load symfony autoloading first
parent::initialize();
// Integrate Zend Framework
require_once('[MY PATH TO ZEND]\Loader.php');
spl_autoload_register(array('Zend_Loader', 'autoload'));
The executeIndex function my the gateway actions.class.php looks like this
// No Layout
$this->setLayout(false);
// Set MIME Type
$this->getResponse()->setContentType('application/x-amf; charset='.sfConfig::get('sf_charset'));
// Disable cause this is a non-html page
sfConfig::set('sf_web_debug', false);
// Create AMF Server
$server = new Zend_Amf_Server();
$server->setClass('MYCLASS');
echo $server->handle();
return sfView::NONE;
Now when I try to visit the url for the gateway module, or even the other module which was working perfectly fine until this attempt, I only see a blank screen, with not even the symfony dev bar loaded. Oddly enough, my symfony logs are not being updated as well, which suggests that Synfony is not even being 'reached'.
So presumably the error has something to do with Zend, but I have no idea how to figure out what the error could be. One thing I do know for sure is that this is not a file path error, because if I change the path in the following line (a part of frontendConfiguration as shown above), I get a Zend_Amf_Server not found error. So the path must be correct. Also if I comment out this very same line, the second module resumes to normality, and my gateway broadcasts a blank x-amf stream.
spl_autoload_register(array('Zend_Loader', 'autoload'));
Does anyone have any tips on how I could attach this problem?
Thanks
P.S. I'm currently running an older version of Zend, which is why I am using Zend_Loader instead of Zend_autoLoader (I think). But I've tried switching to the new lib, but the error still remains. So it's not a version problem as well.
got it...
I was not using
set_include_path()
while loading Zend. It's still odd that it would give such a cryptic error, but this was the missing piece indeed.