I'm starting with angular.js and after reading realized that I should use ng-boilerplate to bootstrap my project. But I'm a bit confused, I've cloned the project and stuff and I have a project called ng-boilerplate with all the structure needed, but what now? Do I need to change the project name "ng-boilerplate" to my project name? And what about the folders for example "Home" and "About"? Do I need to delete these folders and create the ones I need? I guess I have to remove some code in other files right? the problem is that I'm starting with angular so don't know what should I remove and what not.
As you can see I'm pretty new with this, am I right with the procedure?
thanks
Well if you read the ngboilerplate documentation carefully you will understand it use. As the first line says:
ngBoilerplate is designed to make life easy by providing a basic
framework with which to kickstart AngularJS projects.
ngboilerplate like many other seed projects, provide a prescriptive guideline about how a project should be structured. To demonstrate the working of the setup some project like this one add implementation for some standard scenarios to highlight how the complete setup works. Remember a working sample is far better than writing lengthy documentation.
The pages that you have mentioned are indeed for demo purpose and you can remove the folders if required. What this organization is telling us is that group your model-view-controller implementation together into a folder. These folders could be one per view or one per feature. The documentation on the site itself is self explanatory here https://github.com/ngbp/ngbp/tree/v0.3.2-release/src/app
Almost all folders of ngboilerplate have some documentation around specifics of that area. Read it to learn more about it.
Related
I want to use ReactJS for the front end of our new system.
The back end system (in C#) has different modules which can be toggled on/off. Each module has its own set of DLLs, meaning the product can be "shipped" without unnecessary module DLLs. "You need chat functionality? Here's the DLL, drop it in your bin folder, good to go!"
Each DLL is pretty much standalone with no dependency on an other, apart from it's main parent abstraction.
I would like to know, is it possible to create something similar in a React front end? I don't want to have hundreds of react components listed with a bunch of 'if' statements to show/hide them.
I would like each module to be responsible for its own rendering & actions. Adding a brand new feature would be as easy as 'building the extra module' (not updating the 'core' system files to tell it about the extra module).
Gah, I hope that makes sense! Could anyone point me in the right direction? Is this a fools errand? Is it achievable?
Thank you in advance.
This is more question of how to split your frontend code than react specific question. Good news is, it's certainly possible. Take a look at webapack - bundling tool often use with react. I am not sure how exactly modules and DLLs work in C#, but I imagine you have some way how to include different js bundles into them. If so, webpack will help you create these bundles.
in qooxdoo desktop you usually have to develop using the SDK and then "build" your app.
Is there a way to generate something like a qooxdoo.js file with the whole library inside so that you can script script it as you like (like jqueryui or dojo)?
Actually it could be nice to have every widget loaded at runtime like dojo's require("dojo.button") but both the approaches would be nice, just avoiding the build phase.
I hope the question is understandable :)
Thank you everybody!
Don't use the output of the build job to run your code as you develop - as among other things - will minify your code and make debugging very difficult.
If you want to code freely without needing to rebuild when you reference new classes then source-all is the build job for you.
In the root directory of your application, type:
python generate.py source-all
If will include the entire framework in the HTML file generated (you'll find it under source/index.html). This would work well if you are composing the UI from scratch and referencing many new qooxdoo widgets with each browser refresh.
If you add a completely new class of your own, you will need to run the source-all job again to include it.
I use the source build job however for a few reasons:
Habit: source-all didn't exist when I started using qooxdoo
Speed: You can notice a bit of lag it when you refresh the browser to view
your app
References: For a mature app, enough of the framework is
included in the application and its rare to add a new reference and
when you do, its probably in a new class of your own which would
require a re-run of the source job anyway.
I suggest you also look at Default Action Jobs as all the possibilities are explained in detail. Hope this helps.
Please check that thread for a detailed answer: http://qooxdoo.678.n2.nabble.com/Using-qooxdoo-desktop-without-having-to-build-it-td7585015.html;cid=1387453759247-228
Just downloaded the sencha complete trial as I want to try my hand at mobile apps. I am trying to follow the guide located at http://miamicoder.com/2012/how-to-create-a-sencha-touch-2-app-part-1/ just go get an idea of how everything goes. Right off the bat I am having a problem.
The guide at 'Organizing A Sencha Touch Application In Directories And Files' shows the file structure. Well, I open Sencha Architect and choose to create a new Sencha Touch 2.1.x project. Project Inspector shows nothing similar to what the guide does. Is this guide for an older version or what? I am assuming this is my directory structure, but completely different than what is listed.
Help!
The file structure in that guide does appear to be correct, but of course, I would always trust the product from the creator of the framework over an external guide. Thing is, ST2 let's you put things lots of different places and customize those locations in app.js and app.json. I wouldn't worry about the folder structure if you're going through Architect so much as it will put things where they need to go and it'll include them in your app.js file correctly.
That all said, you may want to check the official Sencha documentation on Architect for any questions like this.
I started a trial of Sencha Architect, and the more I use it more questions come to my mind for its actual feasibility usage in a development environment, one of the bigger questions I have is
In an environment that you can't edit the individual files in different editors, how can multiple people collaborate in developing different parts of a site, for example
app/models|components|views/Model1.js <- In charge of developer one
app/models|components|views/Model2.js <- In charge of developer two.
In a regular environment you could use git, for example, to distribute each file but in architect, you are not expected to edit files manually (which sucks because features like profiles are not exposed in architect). If you do edit them manually, it will cause problems or it may overwrite your code back to whatever data is on the project file so I am wondering what is the proper, or expected collaboration workflow with Sencha.
Having read the above posts, I still can't believe that keeping Sencha
metadata files in code repository and generating ALL JavaScript from metadata is suitable for big projects.
The idea of Sencha Architect is to keep the code not in javascript files, but in JSON metadata, and whenever you need to edit a JavaScript code, you have to use IDE and edit metadata. Phil Strong said "We ask that you continue to use Architect as your editor and doing so with 20 engineers is perfectly safe using Git or SVN.". Of course this workflow is very profitable for Sencha, it forces 20 people to use a licensed Sencha Architect, because to change a single line of JavaScript code the developer must use Sencha Architect.
When two people edit the same file, IDE updates metadata. Then they check-in the file into a code repository, and one of them has to resolve conflicts, so the developer has to merge two metadata files, not JavaScript files.
The whole idea of not letting developers to edit JavaScript unless they use Sencha Architect is counter-productive, because the same person can be using his favorite IDE for both Java and JavaScript development, or Python and JavaScript. Doing both client and server programming in the same IDE is faster than switch between two IDE's. The reality of a big project is that you have multiple teams around the globe who work with different IDE's, you also may have a short-term project implemented by a contractor who also has his favorite IDE.
ExtJS is a well designed framework, you don't need SenchaArchitect to modify a single line of JavaScript code.
When coding in JavaScript, I save my JavaScript file and refresh browser, and see the changes immediately. Sencha Archtect adds and additional step, it requires you to publish
javascript (generate JavaScript from metadata), and the bigger the project is, the longer is delay. Often I have to modify JavaScript files in production, sometimes changing a single line fixes the problem, again, I have to use Sencha Architect to re-generate this single line from metadata.
I use Sencha Architect for quick prototyping only, then check-in generated files into code repository and continue to edit JavaScript manually. With this approach I can use a version control system to see the history of JavaScript. If I checked in JSON metadata into
a VCS, then I would not have the history of JavaScript, I would have the history of JSON metadata which is counterintuitive.
I think that having metadata for GUI form is OK, but the limitation that MVC controller level has also to be generated from metadata is not OK.
While I appreciate very much Sencha's effort in creating useful and full-featured dev environment I don't think Sencha Architect is quite ready for relatively big projects and teams of developers.
I original Architect software very useful for quick prototyping and designing complex UI structures, but then again - after you figure out the way your UI elements will lay down in JS file - often it's easier and faster to copy-paste existing JS code.
I don't think this is the answer you were looking for, I just wanted to share my thoughts.
When I had searched for this same topic, I had found that it is the metadata/ directory that is the important meat of the project, and that all of the components are separated out into their own metadata files. This, along with the root level project files, is probably the important part for version control. The app/ is regenerated on save and probably can be excluded from version control.
The main xds project file containers more general references and will probably change less often than the metadata components. But it would change when new components are created or project/app level settings are modified.
Ideally, if you just check in the root files and the metadata folder, it should just work.
Working in a team with source/version control is quite easy with Sencha Architect. An Architect project is all enclosed in a project directory. Inside it's made up of n parts
project file - consists of a small amount of data used by Architect to open and maintain your project. It's the single file you can double click to open it
metadata directory - consists of the files that describe all the pieces of your project. Each class (controller, view, model, store, resource) has it's information stored in it's own file.
app directory - consists of the src of the project you've created. A javascript file for each class.
other root files - an app.html and app.js which is the launchpad for your application and what get's run when you preview your application. This is also where your packager.json, app.json would go.
The point of me describing all of this is to show you that the files generated by Architect are pretty much identical to what you would have created in your favorite editor by hand. The only additional information is the metadata and the project file. The metadata is all JSON.
FOR NOW!!
We ask that you continue to use Architect as your editor and doing so with 20 engineers is perfectly safe using Git or SVN. When a dev makes a change it changes both the metadata and the app for those files.
I asked the same question to Aaron from Sencha in a private message. He suggested to check in the entire project structure including app and metadata.
It works, we did one flow in our team.
Does anyone know of any simple, concise tutorials for packaging DotNetNuke modules for DotNetNuke 4 and DotNetNuke 5? Preferably something concerning DotNetNuke 5.4, since that's what I'm running.
The examples that I've seen all assume background knowledge, or they are about short-cuts to the existing process. I'm a beginner, so I need the simple basics.
Yeah, it's kind of a nightmare the first time.
I started here: Creating a DotNetNuke® Module - For Absolute Beginners! It's DNN 4.x, so a few of the conventions may have changed, but it will probably be close enough to get you going.
Creating a DNN Module and Understanding DNN Architectural Approach goes into more detail:
I suppose the important concept is: you're writing a WebControl using the MVC pattern. The DNN Module Wizard will create a "view" page for you, and you add code to suit.
there's some good resources here for info on packages:
http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/1140/Packaging-and-protecting-your-DotNetNuke%C2%AE-Module.aspx
by Michael Washington (mentioned above)
http://www.dotnetnuke.com/Development/Forge/ModuleReports/tabid/970/EntryId/453/DotNetNuke-4-3-Starter-Kit-and-Item-Templates.aspx
by Shaun Walker
Simple basics...
When you start with the DNN module template in Visual Studio there's a standard .dnn file there. this file must be modified to include all files needed to run the module (resx, images, dlls, ascx, .sqldataprovider) without any of the sourcecode files (.cs, .vb).
zip all of the files mentioned in the .dnn file up with the dnn file (all files in root of the zip) and submit it to the upload new module page (logged in as Host).
the zip is automatically extracted, the .dnn file is read and all files are placed in the appropriate places.
resources for creating packages:
http://www.codeproject.com/KB/dotnet/DnnModulePackager.aspx
http://www.mitchelsellers.com/blogs/articletype/articleview/articleid/200.aspx
by looking at these you can also further your understanding of package creation.
i'm using 4.9 currently so someone may want to correct me on changes that i'm unaware of.
Google for Michael Washington and / or Mitchel Sellers and they have excellent work on Module Development.
Mark Breen
Ireland
Chris Hammond has recently written two blog posts on dotnetnuke.com about packaging modules, you should really have a look that those, they are super, he tells you how to set up your environment and how to create a C#Template for your modules.
thanks
Mark
A good place to start is use the IFrame module. It's all code behind so no compile needed before deployment. Look in the dnn file to see where the files are copied to.
You might also want to look at https://github.com/dazinator/DnnPackager which is a NuGet package that when added to your module project, automates production of the install zip, and has other features