I'm hitting this issue in this latest project where I'm looking to organise my code into subdirectories. However by doing so, the main application .pde file can't "see" the classes in the subdirectory.
Example - Say my folder structure is:
PFoo /
- PFoo.pde
PSystem /
- PSystem.pde
- Particle.pde
With PFoo.pde as my main application file, I can't seem to access the PSystem class or Particle class. Now, I guess the general consensus would be to develop a library to import or just deal with all the .pde files being in the same directory, however I'm wondering if there is something simple that I'm missing here that will enable me to quickly sort out the numerous class files that will be created. Something like a include "PSystem/PSystem.pde" or....
You can't have a tree structure in the Processing IDE unfortunately.
All your tabs from Processing end up being nested and compiled into a single Java class when you press Run.
I recommend using eclipse and you can easily nest your classes into java packages.
Additionally you can use the Proclipsing plugin which integrates nicely and makes it easier to manage libraries/export sketches/etc.
Related
Working with the excellent fbs tool (great stuff Michael!).
The manual has this suggestion about project structure:
As your application grows in complexity, you will likely want to split
its source code across multiple files. In this case, it is recommend
that you place them all inside one package.
My tendency is to use subdirectories like 'view','controller','model','service', etc wherein multiple .py files exist. Is there a critical reason one wouldn't want to use subdirectories when using fbs?
I am building a web application in Go and as part of it I have several middelware functions defined. Right now they all live in "my/middleware" package. That namespace is becoming very cluttered by all the different functions I've defined so I decided to put them all in their own subdirectories, e.g. "my/middleware/gzip". When I do this I get the error:
no buildable Go source files my/middleware
I don't want all of these functions in the same namespace, but it seems my only option is to create a placeholder .go file in the my/middleware directory with an empty init function or something. That sounds terrible so I'd like suggestions on how to achieve my goal to group a similar class of packages when there isn't any shared/common code to live in the parent package.
You are actually taking the right decision by splitting the files into different subfolders. It is not different than what is done here
https://golang.org/pkg/compress/
This allows for the clients of your framework to take only what they need. The idea is to avoid dependency bloating. Go is all about being lean.
The error you receive is because you try to build a package that doesn't exist. Think of that folder as a logical grouping mechanism, you need to build the packages given by the child folders individually.
I'm playing with golang and made a tool for password generation. Initially it was intended to be used as a command line tool. I later separated the generation logic into a separate package (still same github repository) and left the main function in the root of the project. Now I also want to add a simple web frontend (nothing fancy), but I don't know how to structure the packages.
Am I supposed to put both the command line entry point as well as the web UI into their own packages in the same project (which leaves the root empty). Or maybe I should move the actual generation library to the root and the UIs in separate packages. I guess the other option is to have the UIs in separate projects on github, but they are only going to be used for this library, so it does not seem like a good idea.
I remember seeing in some projects packages named cmd for example, but never have I encountered one, with multiple front ends. Is there a go(-gettable-)way for doing this?
I agree that there's not much point in making separate projects/repositories if they're only going to be used for this library. I would just have a cmd directory with a subdirectory for each executable you're building.
Something like this:
github.com/user/project
generation
cmd
cmdline
main.go
web
main.go
The main.go files can use the functionality that you've broken out into your "generation" package.
The name of the executables produced by go build will be the name of the parent directory, so cmdline and web in this example (you would want to choose better names).
Note: you don't actually have a package cmdline or web. The files in those directories would all be in [their own separate] package main.
Here's how I usually develop an application:
I start with having all the code in a single source file.
When it grows enough to be modularised, I break the code into several modules.
When the modules grow enough, I split them again. And so on, iteratively.
Over time, some modules get shrunk, deleted or merged with others.
This workflow implies the need to move source files between modules sometimes. And here comes the problem:
When I move a module to another location, it changes the module's name, so I have to walk through all the other files renaming imports by hand.
Is there some organisational technique to avoid that annoying procedure? Or is that the way it goes and I just have to look into some automation utilities instead?
you can create a *.all module that public imports all modules in the package
then you only need to add/remove the module names from that module
You can override module name via module packagename.modulename; directive in the beginning of the module. It will need a help from the build system though as rdmd uses module names from import statements to form file system path to search for their sources. But if you will supply all source files project consists from by hand, it should resolve module names just fine.
It's better to define your entities before you start coding. You can use some modelling language to identify and write your entities. For example if you are using java to code your application then you can use UML to model this application.
Also, you have to separate buisness logic from data.
If you continue to do it like today you will lose a lot of time just dealing with filenames.
I have been using the Codesmith framework NetTiers to generate a DAL etc., into a folder called, say, 'NetTiers', outside my main project's folder, and referencing the DLLs within that folder from my main project.
I've started using the Plinqo framework, and want to use the generated files from that framework within the same project as the one I'm using with NetTiers. (The reason I'm using both frameworks is that I want to get/learn the newer LINQ goodness from Plinqo, yet also have the familiar NetTiers code DAL, BLL syntax available, for compatibility.)
My question is: what's the best Visual Studio solution and file structure to use when using Codesmith templates like these? Should the frameworks' generated code be contained outside the main project and added as projects to the overall solution? Or should each template's generated code have its own solution? Should the generated files be within the main project's file structure?
I've tried combinations of each of these, and they each have their pros and cons. I'd like to know if there's a tried and tested pattern.
When it comes to .netTiers, I always compile the generated solution and add the assemblies as references to my project. This makes it much easier to upgrade/diff and regen.
However, there are going to be some cases where you would want to add your custom logic so keep this in mind.
Thanks
-Blake Niemyjski
I tend to just keep the .csp and the generated folder outside of my main app's folder. When adding a reference Visual Studio copies in the .DLLs from the built generated code. All of the generated projects sit under a main folder such as D:\CodeSmith Projects\
If you want to version control the .csp file it might be beneficial to move it in with the rest of your version controlled app files to tie it all together.
We put the generated projects inside our solution. In fact on my current project I generated the nettiers files to the location that I wanted the files to be, and Started adding my own project files to that...But we have always kept the files in the solution, that way if i need to add something to the code in the concrete classes I can do it without having to open a whole new project.
We have tried both scenarios. We settled for including the assemblies in a dependencies folder, which was shared by multiple projects.
We had problems with TFS when the projects were included in the solution. the downside, is that you can't so easily step into the .NetTiers generated code when debugging, though after a while you get used to this, and accept that whatever is in .NetTiers stays within .NetTiers!