How do I get the list of classes from an inherited module programmatically?
Let's say I inherit from module com.example.Example, how can I get the classes involved with the module?
In GWT, at run-time, you can't really. When the GWT compiles from your java files into javascript, it obtusifies all the names of methods and variables. The names literally don't exist at run-time.
You would have to create something that runs at compile time, like a generator, that processes a directory when you compile your code. You can google how to do it, but you might want to rethink why you need the class listing, or see if you can move that functionality on to your server side.
There is no tool for doing that except setting log level to TRACE during compile time and see all modules being visited.
You can use as reference this 'GraphDependencies tool' written by Thomas Broyer some time ago and which is pending to review.
You can use the ResourceOracleImpl for getting all resources calling the oracle.getResources() or the oracle.getResourceMap() which groups resources, instead of the oracle.getPathNames() utilised in this class.
Related
Is there a generic way to prevent a given set of files from being parsed by IntelliSense modules while it still shows up elsewhere?
For instance, I have a third-party library that provides an AppModel class I can customise. Such class is defined in several places:
The library bundles a template to copy from.
The library includes a usage example.
The library implements the class in a helper tool.
The library defines the class for its test harness.
I implement the class in my app.
My implementation is the only one that gets loaded when the app runs and the only one I care about when I navigate my code or use Go to Symbol yet I need to pick among the 5 definitions every time.
For languages where there isn't a specific setting, the only way to go appears to be files.exclude. But that directive basically makes the file or directory completely disappear from the program. It won't even show up in the Explorer pane. That feature seems designed for source control metadata and similar stuff and I don't think it's entirely convenient for third-party libraries.
Any idea?
I'm trying to learn about Package interfaces and use access.
I have 2 hierarchies of packages
1:
ZAVG_TRAINING-PACKAGE1 containing
...
ZAVG_TRNG_SUBPKG3
2:
ZAVG_TRNGPKG_2_STRUCT_SUBPKG_1 containing
ZAVG_TRAINING_PACKAGE2 containing
ZAVG_TRNGPKG2_SUBKPG_1
In the first hierarchy, all the packages are not main packages.
In the second, the base package is a structure package, the next is a main package and the third is a non-main package.
In ZAVG_TRNG_SUBPKG3 (in the first hierarchy), I have a view ZAVG_V_MARA and a program ZAVG_DELETE_THIS_8. I also have a package interface exposing the program, and no use accesses granted.
My problem is that from a program contained in the package ZAVG_TRNGPKG2_SUBKPG_1 I can access both the objects contained in ZAVG_TRNG_SUBPKG3 with no restrictions.
As far as I see from the documentation, in order for a development object to be visible from packages outside the current package (except the outer package). I should have to add them all to the package interface and also create use accesses for the packages that should be allowed to use that interface.
What am I doing wrong?
As long as you're not planning to build something as complex as, let's say, the Enterprise Core Components, and planning to sell it to hundreds and thousands of anonymous customers who are in the mood of suing you if you change published interfaces, I wouldn't bother with the package access control. I know that doesn't answer your question, but all you'll end up with is a lot of wasted time and no advantages whatsoever. You'll have to tweak the package structure in illogical and really counter-intuitive to get things working.
In your case, there are quite a number of things that could have gone wrong - for example, the system-wide package checking switch might be turned off. Then, you'll have to remember that the checking only ever takes place at design time and never when running the program. Finally, as far as I remember, the check is not performed automatically - you'll have to execute it either manually or using some automated tool.
To manually check the package you can do it from the menu in the ABAP workbench:
Or by right-clicking on the object list:
However, as vwegert said: it is very likely that the package check is just not turned on in your system (I have not worked on a single system that had it turned on).
Ie. I have a GUI package, and a Logic package.
How can I prevent the Logic classes from importing GUI classes? Others(or myself) working on the same project might do that, which I want to prevent.
A solution could for example be a check in JUnit, that fails if its done, or a runtime check that throws an exception. Something along these lines, but how to do it?
You can write such a test using JDepend or DependencyFinder or Degraph.
Degraph is the only of the three tools that explicitly is intended to actually write tests for cases like this. Also AFAIK JDepend does not find all dependencies in more recent Java Versions (like classes mentioned in Annotations).
I'm the author of Degraph so I'm obivously biased.
I created the JabSaw project. It allows you to define modules by using annotated classes and to express the relationships between the modules. By default, a module contains all classes in a single package.The restrictions can be checked using a Maven plugin, from the command line or from a unit test. This should solve your problem.
One solution which comes to my mind is make GUI classes package private. Although you cannot isolate only one package and say, only Logic classes cannot use GUI, but other can.
I completed my very first project in zend framework!! Thanks to stackoverflow community!!
While uploading files, i didn't know how to include zend library so i uploaded the whole library in the /library folder of my project base.
Is there a way to determine which library is used and which in not (like compilation that automatically copies dependent files to library folder incase webhost does not provide zend library ..)? i would be awfully bad to manually add each file and test weather the particular library is added or not.
This answer essentially says don't worry about including the whole library. I usually put the whole library in the project library folder, just like you did.
But if it is truly problematic to include the whole library, you could take a look at Jani Hartikainen's Packageizer which, at least in a previous form that I played with, allowed you to specify the components you needed and it would chase the dependencies and wrap them in a neat little package.
Disk space is cheap. Just have the entire ./Zend library directory (and maybe ./ZendX, if you are using that) into your own library directory where it will used. With autoloading, nothing that isn't being used will take up any significant memory. taking even 5 minutes trying to figure out is time (and therefore money) that is more usefully spent writing code.
I wonder if it would be worthwhile/reliable to subclass the autoloader for this and have it optionally log each class it loads during site operation (sort of how Zend_Translate can log untranslated strings).
You could have it turned off normally but in your testing environment you would turn it on (via your application.ini), and have it build your dependency list while your unit tests are running.
In order to provide nice URLs between parts of our app we split everything up into several modules which are compiled independently. For example, there is a "manager" portion and an "editor" portion. The editor launches in a new window. By doing this we can link to the editor directly:
/com.example.EditorApp?id=1
The EditorApp module just gets the value for id and loads up the document.
The problem with this is ALL of the code which is common between the two modules is duplicated in the output. This includes any static content (graphics), stylesheets, etc.
And another problem is the compile time to generate JavaScript is nearly double because we have some complex code shared between both modules which has to be processed twice.
Has anyone dealt with this? I'm considering scrapping the separate modules and merging it all back into one compile target. The only drawback is the URLs between our "apps" become something like:
/com.example.MainApp?mode=editor&id=1
Every window loads the main module, checks the value of the mode parameter, and and calls the the appropriate module init code.
I have built a few very large applications in GWT, and I find it best to split things up into modules, and move the common code into it's own area, like you've done. The reason in our case was simple, we had some parts of our application that were very different to the rest, so it made sense from a compile size point of view. Our application compiled down to 300kb for the main section, and about 25-40kb for other sections. Had we just put them all in one the user would have been left with a 600kb download, which for us was not acceptable.
It also makes more sense from a design and re-usability point of view to seperate things out as much as possible, as we have since re-used a lot of modules that we built on this project.
Compile time is not something you should generally worry about, because you can actually make it faster if you have seperate modules. We use ant to build our project, and we set it to only compile the GWT that has changed, and during development to only build for one browser, typical compile times on our project are 20 seconds, and we have a lot of code. You can see and example of this here.
One other minor thing: I assume you know that you don't have to use the default GWT paths that it generates? So instead of com.MyPackage.Package you could just put it into a folder with a nice name like 'ui' or something. Once compiled GWT doesn't care where you put it, and is not sensitive to path changes, because it all runs from the same directory.
From my experience building GWT apps, there's a few things to consider when deciding on whether you want multiple modules (with or without entry points), or all in one: download time (Javascript bundle size), compile time, navigation/url, and maintainability/re-usability.
...per download time, code splitting pretty much obviates the need to break into different modules for performance reasons.
...per compile time, even big apps are pretty quick to compile, but it might help breaking things up for huge apps.
...per navigation/url, it can be a pain to navigate from one module to another (assuming different EntryPoints), since each module has it's own client-side state...and navigation isn't seamless across modules.
...per maintainability/re-usability, it can be helpful from an organization/structure perspective to split into separate modules (even if there's only one EntryPoint).
I wrote a blog post about using GWT Modules, in case it helps.
Ok. I really get the sense there really is no "right" answer because projects vary so much. It's very much dependent on the nature of the application.
Our main build is composed of a number of in-house modules and 3rd party modules. They are all managed in seperate projects. That makes sense since they are used in different places.
But having more than one module in a single project designed to operate as one complete application seems to have overcomplicated things. The original reason for the two modules was to keep the URL simple when opening different screens in a new window. Even though had multiple build targets they all use a very large common subset of code (including a custom XML/POJO marshalling library).
About size... for us, one module was 280KB and the other was just over 300KB.
I just got finished merging everything back into one single module. The new combined module is around 380KB. So it's actually a bit less to download since most everyone would use both screens.
Also remember there is perfect caching, so that 380KB should only ever downloaded once, unless the app is changed.