1
0
Fork 0

typos etc.

This commit is contained in:
Jan Steemann 2015-02-17 09:05:00 +01:00
parent 44262ecb2e
commit cc42bdabf4
1 changed files with 47 additions and 39 deletions

View File

@ -1,56 +1,64 @@
v2.5.0-alpha2 (2015-02-16)
-------------------
* Simplify the entry to foxx
* Simplify usage of Foxx
Thanks to our user feedback we learned that foxx is a powerful, yet rather complicated concept.
With this release we tried to make it less complicated while keeping all it's strength.
Thanks to our user feedback we learned that Foxx is a powerful, yet rather complicated concept.
With this release we tried to make it less complicated while keeping all its strength.
That includes a rewrite of the documentation as well as some code changes as listed below:
* Moved Foxx applications to a different folder.
The naming convention now is: <app-path>/_db/<dbname>/<mointpoint>/APP
Before it was: <app-path>/databases/<dbname>/<appname>:<appversion>
This caused some trouble as apps where cached based on name and version and updates did not apply.
Hence the path on filesystem and the url to access had no relation to one another.
Now the path on filesystem is identical to the url (except for slashes and the appended APP)
* Moved Foxx applications to a different folder.
The naming convention now is: <app-path>/_db/<dbname>/<mointpoint>/APP
Before it was: <app-path>/databases/<dbname>/<appname>:<appversion>
This caused some trouble as apps where cached based on name and version and updates did not apply.
Hence the path on filesystem and the app's access URL had no relation to one another.
Now the path on filesystem is identical to the URL (except for slashes and the appended APP)
* Rewrite of Foxx routing
* Rewrite of Foxx routing
The routing of Foxx has been exposed to major internal changes we adjusted because of user feedback.
This allows us to set the development mode per mountpoint without having to change pathes and hold
apps at seperate locations.
The routing of Foxx has been exposed to major internal changes we adjusted because of user feedback.
This allows us to set the development mode per mountpoint without having to change pathes and hold
apps at seperate locations.
* Foxx Development mode
* Foxx Development mode
The development mode used until 2.4 is gone. It has been replaced by a much more mature version.
This includes the deprecation of the javascript.dev-app-path parameter which is useless since 2.5
Instead all apps are located at the same location production as well as development.
But you can set specfic apps into development mode changeing their behaviour compared to
production apps: They are rerouted from disc on any request, they ship more debug output on routes.
The development mode used until 2.4 is gone. It has been replaced by a much more mature version.
This includes the deprecation of the javascript.dev-app-path parameter, which is useless since 2.5.
Instead of having two separate app directories for production and development, apps now reside in
one place, which is used for production as well as for development.
Apps can still be put into development mode, changing their behavior compared to production mode.
Development mode apps are still reread from disk at every request, and still they ship more debug
output.
* Foxx install process
* Foxx install process
Installing of foxxes has been a two step process: import them in arangodb and mount them on a
specific mountpoint. These operations have been joined together. You install an app on one
mountpoint, thats it. No fetch, mount, unmound, purge anymore.
* Install: get your foxx up and running.
* Uninstall: shut it down and erase it from disc.
Installing Foxx apps has been a two step process: import them into ArangoDB and mount them at a
specific mountpoint. These operations have been joined together. You can install an app at one
mountpoint, that's it. No fetch, mount, unmount, purge cycle anymore. The commands have been
simplified to just:
* Foxx error output
* install: get your Foxx app up and running
* uninstall: shut it down and erase it from disk
Until 2.4 the errors produced by foxx where not optimal. If any they created only in internal
stack trace and always returned with 'unable to parse manifest'.
In 2.5 we made major improvements there, including a much more finegrained error output that
helps you debug your foxxes. The error is now much closer to it's source and should help you
track it down.
Also we added the default handlers for unhandled errors in your foxxes.
* You will get a nice internal error page whenever your foxx cannot be installed.
* You will get a propper error message when having an unhandled error in your route.
In production mode the messages above will NOT contain any information about your foxx internals
and are save to be exposed to third party.
In development mode the messages above will contain the stacktrace if available making it easier for
your in-house devs to track down the errors in their application.
* Foxx error output
Until 2.4 the errors produced by Foxx were not optimal. Often, the error message was just
`unable to parse manifest` and contained only an internal stack trace.
In 2.5 we made major improvements there, including a much more finegrained error output that
helps you debug your Foxx apps. The error message printed is now much closer to its source and
should help you track it down.
Also we added the default handlers for unhandled errors in Foxx apps:
* You will get a nice internal error page whenever your Foxx app is called but was not installed
due to any error
* You will get a proper error message when having an uncaught error appears in any app route
In production mode the messages above will NOT contain any information about your Foxx internals
and are safe to be exposed to third party users.
In development mode the messages above will contain the stacktrace (if available), making it easier for
your in-house devs to track down errors in the application.
* added optimizer rule `propagate-constant-attributes`