eis-devel — General developers list

Re: [Eis-devel] question

[Bas L. <ba...@ba...>]

Hi Luuk,

First of all apologies for my terribly late reaction.

I think that installation of modules should be done by simple creating 
zip archives of a module
directory. The install tool in the servermanager should then in my 
opinion first extract this zip file to
a temporary location. This temporary directory can then be checked to 
verify that the zip is indeed
a valid EIS module (contains a module.xml, elements dir, locales, 
services etc.) and basic info from the
module.xml can be displayed. If everything is ok you can then choose to 
install the module to the modules
directory.

Cya

Bas

Luuk van den Broek wrote:
> He guys,
>
> Iv'e done some work on the servermanager. Almost all elements are done. 
> Only thing left are the dependencies between environments and 
> applications and such.
>
> Another thing that is left is the element that used for adding modules. 
> I was wondering what methods we were going to use to add modules. Just 
> normal folders or zips and if the modules would be prepackaged and done 
> or stuff like module.xml should be rendered if not present , Possible 
> checks? etc...
>
> I was thinking that at least support for compressed modules should be 
> added (zip tar etc.) The rest i'm not sure about.
>
> Let me know
>
> Luuk
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Eis-devel mailing list
> Eis...@li...
> https://lists.sourceforge.net/lists/listinfo/eis-devel
>   

[Eis-devel] question

[Luuk v. d. B. <luu...@gm...>]

He guys,

Iv'e done some work on the servermanager. Almost all elements are done. 
Only thing left are the dependencies between environments and 
applications and such.

Another thing that is left is the element that used for adding modules. 
I was wondering what methods we were going to use to add modules. Just 
normal folders or zips and if the modules would be prepackaged and done 
or stuff like module.xml should be rendered if not present , Possible 
checks? etc...

I was thinking that at least support for compressed modules should be 
added (zip tar etc.) The rest i'm not sure about.

Let me know

Luuk

[Eis-devel] What to do with errors...

[Bas L. <ba...@ba...>]

Hi All,

I have been working on the servermanager application and got the feeling 
that the way user errors are currently handled in EIS is not
the best way to go. So please think with me, and let me know how you 
think that errors should be handled.

My first question is whether a service should stop immediately after an 
error is found. EIS1.5 services do not and try to find all errors
and return them as an array. The other option is to stop when the first 
error is found and return only one. One error is more simple than 
finding all errors and will provide one specific reason why a process is 
cancelled with a single error message. An array of errors can be 
helpfull when many things are wrong that can be fixed by the user before 
resubmitting.

The second question is at what point translation of error messages 
should be handled. One option is to do translation in the service when 
an error is detected. This is easy because all the information for 
construction is directly available but also means that when a service is 
invoked it will have to be language aware. This is a bit awkward when 
calling services via xml-rpc for example. Another option is to leave 
translation of error messages to elements or rpc clients. This is a more 
presentation independent solution but does mean that the client will 
need to be able to translate string identifiers to text and that 
information that has to be replaced in the messages will have to be 
provided as well. For example, a message like "The username 'johndoe' is 
already in use" should be constructed from a code "e.username.taken" and 
the replacement "johndoe". This would mean that error objects become 
more complex than just numbers or strings.

My current preference would be to stop when the first error is found and 
to do translation in elements or rpc-clients.
What are your thoughts?

greetz,
Bas

Re: [Eis-devel] [Eis-commits] SF.net SVN: eis: [196] trunk

[Bas L. <ba...@ba...>]

Hi Luuk,

nice to see you got the environments section of the server manager 
working again without problems.
Most of the work on the other sections has been done, but I'm still 
working on an easier way to provide feedback after
input checking in an action. User feedback on actions is important but 
was a bit of a hassle in EIS1.5 so it is often missing
or not very helpful. I would like to add an easier method for elements 
to provide error messages and other feedback. When
that feature is available, I guess all the large changes (on how 
elements are used) are done and we can finish the
server manager and continue with other things like authentication, user 
management and file + image storage.

grtz,
Bas

luu...@us... wrote:
> Revision: 196
>           http://eis.svn.sourceforge.net/eis/?rev=196&view=rev
> Author:   luukvandenbroek
> Date:     2007-08-21 02:08:01 -0700 (Tue, 21 Aug 2007)
>
> Log Message:
> -----------
> solved conflicts for last update and some minor work hung up on getting data from forms to the action function please advise if work is being done or if it's still open
>
>   

Re: [Eis-devel] Proposal for different template libary

[Bas L. <ba...@ba...>]

Hey Tom,

using a smarty or other useful third party libraries looks like a smart 
idea to me. However, I don't really like including third party libraries 
into the EIS distribution because it will require more maintenance and 
will bloat
EIS. Therefore I would like to propose to wrap smarty in a module (e.g. 
"lib_smarty") and maintain a separate directory with optional modules in 
the svn repos. This will keep the EIS core clean but will allow for easy 
extension
of EIS with smarty.
What is your opinion on such a construction?

grtz,
Bas

Tom van den Broek wrote:
> Hi,
>
> I'm reading up on Smarty http://smarty.php.net/ a template library in 
> the same manner a the current EIS template lib.
>
> I would like to propose to replace the current template lib with the 
> smarty template library. Its basic usage is almost exactly the same 
> while it also has more advanced features (See below).
> *
> Some of Smarty's features:*
>
>    *
>
>       It is extremely fast.
>
>    *
>
>       It is efficient since the PHP parser does the dirty work.
>
>    *
>
>       No template parsing overhead, only compiles once.
>
>    *
>
>       It is smart about recompiling
>       <http://smarty.php.net/manual/en/variable.compile.check.php>
>       only the template files that have changed.
>
>    *
>
>       You can easily create your own custom functions
>       <http://smarty.php.net/manual/en/language.custom.functions.php>
>       and variable modifiers
>       <http://smarty.php.net/manual/en/language.modifiers.php>, so the
>       template language is extremely extensible.
>
>    *
>
>       Configurable template {delimiter}
>       <http://smarty.php.net/manual/en/variable.left.delimiter.php>
>       tag syntax, so you can use {$foo}, {{$foo}}, <!--{$foo}-->, etc.
>
>    *
>
>       The {if}..{elseif}..{else}..{/if}
>       <http://smarty.php.net/manual/en/language.function.if.php>
>       constructs are passed to the PHP parser, so the {if...}
>       expression syntax can be as simple or as complex an evaluation
>       as you like.
>
>    *
>
>       Allows unlimited nesting of sections
>       <http://smarty.php.net/manual/en/language.function.section.php>,
>       if's etc.
>
>    *
>
>       It is possible to embed PHP code
>       <http://smarty.php.net/manual/en/language.function.php.php>
>       right in your template files, although this may not be needed
>       (nor recommended) since the engine is so customizable
>       <http://smarty.php.net/manual/en/plugins.php>.
>
>    *
>
>       Built-in caching <http://smarty.php.net/manual/en/caching.php>
>       support
>
>    *
>
>       Arbitrary template
>       <http://smarty.php.net/manual/en/template.resources.php> sources
>
>    *
>
>       Custom cache handling
>       <http://smarty.php.net/manual/en/section.template.cache.handler.func.php>
>       functions
>
>    *
>
>       Plugin <http://smarty.php.net/manual/en/plugins.php> architecture
>
>
> Tom.
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Eis-devel mailing list
> Eis...@li...
> https://lists.sourceforge.net/lists/listinfo/eis-devel
>   

[Eis-devel] Proposal for different template libary

[Tom v. d. B. <tom...@gm...>]

Hi,

I'm reading up on Smarty http://smarty.php.net/ a template library in the
same manner a the current EIS template lib.

I would like to propose to replace the current template lib with the smarty
template library. Its basic usage is almost exactly the same while it also
has more advanced features (See below).
*
Some of Smarty's features:*


   -

   It is extremely fast.
   -

   It is efficient since the PHP parser does the dirty work.
   -

   No template parsing overhead, only compiles once.
   -

   It is smart about
recompiling<http://smarty.php.net/manual/en/variable.compile.check.php>only
the template files that have changed.
   -

   You can easily create your own custom
functions<http://smarty.php.net/manual/en/language.custom.functions.php>and
variable
   modifiers <http://smarty.php.net/manual/en/language.modifiers.php>, so
   the template language is extremely extensible.
   -

   Configurable template
{delimiter}<http://smarty.php.net/manual/en/variable.left.delimiter.php>tag
syntax, so you can use
   {$foo}, {{$foo}}, <!--{$foo}-->, etc.
   -

   The {if}..{elseif}..{else}..{/if}<http://smarty.php.net/manual/en/language.function.if.php>constructs
are passed to the PHP parser, so the
   {if...} expression syntax can be as simple or as complex an evaluation
   as you like.
   -

   Allows unlimited nesting of
sections<http://smarty.php.net/manual/en/language.function.section.php>,
   if's etc.
   -

   It is possible to embed PHP
code<http://smarty.php.net/manual/en/language.function.php.php>right
in your template files, although this may not be needed (nor
   recommended) since the engine is so
customizable<http://smarty.php.net/manual/en/plugins.php>.

   -

   Built-in caching <http://smarty.php.net/manual/en/caching.php> support

   -

   Arbitrary template<http://smarty.php.net/manual/en/template.resources.php>sources
   -

   Custom cache
handling<http://smarty.php.net/manual/en/section.template.cache.handler.func.php>functions
   -

   Plugin <http://smarty.php.net/manual/en/plugins.php> architecture


Tom.

Re: [Eis-devel] [Eis-commits] SF.net SVN: eis: [182] trunk/mod/eis_engine

[Bas L. <ba...@ba...>]

Hi Luuk and everybody else,

I'm sending this reply to the list to prevent others from running into 
the same problem.
The catchall tag is working just fine, but it appears that you have 
overlooked the error check in my
DisplayWebService element while copying it to create a 
DisplayEnvironment element. There is a check that
triggers a 404 error in the engine when a webservice is not found. The 
reason for this is to create consistent behaviour
between dynamic and static pages. If a static page defined in the 
application xml the engine will output a 404 error, so dynamic
pages should also generate a 404 when the object that the name of the 
dynamic page refers to is not found. Conceptually you could
think of it as that there is a display page for each webservice or 
environment. If a non existing name is used in the url to reference such 
a display page, it should result in a page not found error.
Hope this helps :)

CYA
Bas

luu...@us... wrote:
> Revision: 182
>           http://eis.svn.sourceforge.net/eis/?rev=182&view=rev
> Author:   luukvandenbroek
> Date:     2007-06-18 11:57:05 -0700 (Mon, 18 Jun 2007)
>
> Log Message:
> -----------
> SelectEnvironment works except for the linking to the dynamic pages from the element some prob with the cathall tag in the servermanager.xml DisplayEnvironment is real element the rest are mock elements
>   

[Eis-devel] repository cleanup

[Bas L. <ba...@ba...>]

Hey Guys,

I just cleaned up the EIS repository structure. Read the commitlog for 
more details (http://eis.svn.sourceforge.net/eis/?rev=176&view=rev).
The reason for this followup mail is that the cleanup also influences 
the current development trunk. It has been renamed from "trunk_1.6" to 
just "trunk". Therefore you will have to switch your checkouts. Just run 
"svn switch https://eis.svn.sourceforge.net/svnroot/eis/trunk" in the 
root of your checkout.

Sorry for the inconvenience.

Bas

[Eis-devel] back to basic widgets

[Bas L. <ba...@ba...>]

Hey all,

since the use of an advanced widget toolkit like dojo or something 
similar is not going to be anytime soon, I'm working to get the widget 
module working again. While I was doing this I had an idea that I will 
need you to help me with. I was thinking about trimming the widget 
module to a very basic widget set, with nothing more than widgets to 
build forms with and do some basic presentation with. I would like to 
strip the templated themes from the widget module and make widgets only 
themable using different css and images. The html will be fixed and 
directly generated in the service. I think that by doing this we will 
have a widget module that provides a little extra on top of plain html 
to use for creating consistent good looking forms tables and buttons but 
will be a lot less high maintenance than the 1.5 widget module, which is 
too complicated at some points, but too simplistic at others.
So, what do you guys think? Is this approach too drastic, or should I 
just go ahead and strip everything down to a slim basic widget set?

grtz,
Bas

PS
Luuk, I know how much trouble it was to build the templated widgets, 
sorry to undo that work with this.

[Eis-devel] 1.6 progress update

[Bas L. <ba...@ba...>]

Hey Guys,

I just committed a bunch of changes to the eis 1.6 libraries. It is 
almost ready for the construction of the server manager application. The 
two showstopper features that are still missing are: sessions and 
widgets. I hope to have them working again soon. I don't expect a lot of 
trouble on these parts because they will change little, just enough to 
fit them to the changed libraries.
So please check the changes I made so far 
(http://eis.svn.sourceforge.net/eis/?rev=173&view=rev) and start bugging 
me if the remaining changes on the session and widget are not done fast 
enough :) Maybe we should get together when these changes are done, to 
kickstart the development of the server manager app.

grtz,
Bas

[Eis-devel] widget frameworks

[Bas L. <ba...@ba...>]

Hey Guys,

this link was posted on slashdot today:

http://www.ddj.com/199203087;jsessionid=PLXEGALNMZNM0QSNDLRSKH0CJUNN2JVN?_requestid=1401663

It is a comparison of three javascript widget/ajax toolkits: dojo, 
prototype/scriptaculous and YUI. It is
an interesting read and could help in finding an appropriate widget 
toolkit for EIS.

Bas

Re: [Eis-devel] specs application manager

[Bas L. <ba...@ba...>]

Hi Luuk,

nice job! I read the specs and consider them a good start. There is one 
thing that I'm not sure about: user and database management. I would 
like EIS to be able run without an SQL database. This way it will be 
easier to setup for services or applications that do not need to store 
any data. Obviously the servermanager application will need at least one 
(administrator) user. Which leaves the question where to store these 
users. And we will also need some temporary datastore for sessions. The 
design of these features will heavily influence the initial setup procedure.

If we can come up with a design in which we have users and sessions for 
the manager app without and SQL database we don't need a mandatory 
initial setup but can offer it as an optional feature for novice users. 
Expert users might prefer to define environments in the server manager 
themselves.

Would you, and the others as well, think with me about the bootstrap of 
having users before having a database? If we can think of, and agree 
upon a solution on how to do this, I think we have described enough to 
start on a rough first version of the manager app. I will design a 
graphical layout for this somewhere soon so we have a structure to work 
with.

cya,

Bas

Luuk van den Broek wrote:
> He people,
>
> I've committed the beginning of specs for the application server
> manager. You can find them in the same place as the 1.6 specs
> (developer/docs/specs). Let me know what you think.
>
> Luuk
>   

[Eis-devel] specs application manager

[Luuk v. d. B. <luu...@en...>]

He people,

I've committed the beginning of specs for the application server
manager. You can find them in the same place as the 1.6 specs
(developer/docs/specs). Let me know what you think.

Luuk
-- 
*EntiQ BV*
/The Integration Company/

Luuk van den Broek

Postbus 86
6500 AB Nijmegen

W www.entiq.nl
E in...@en...

T +31 (0)24 360 6585
F +31 (0)24 360 9022

Re: [Eis-devel] 1.6 specs

[Bas L. <ba...@ba...>]

Hey Luuk,

thanks for going over the specs! I agree we should proceed with the 
specification of the configuration app.
I think that the most basic version should include:
- Module management: That is installation and upgrading of modules.
- Application deployment: Deployment of applications on the server
- Webservice deployment: Deployment of webservices on the server
- Database/datadir environment management: Manage different environments 
to deploy applications to. These environments contain database, datadir 
and access restriction config.

Since you don't really need a tool to manage the modules (tar and scp 
will do for now) I think we should start with application and webservice 
deployment.
Would you like to add a proposal for these features to the specs 
document? We could use that as a start for further specifcation.

Bas

Luuk van den Broek wrote:
> He all,
>
> I don't have much to add to the 1.6 specs. They look good to me. I think
> next we should start on the specs for the configuration app. These specs
> should be made with in mind what 1.6 needs to be capable of rather than
> what it's capable of now. Therefor I think these specs should be quite
> rigid, so the work that needs to be done on 1.6 naturally flows from the
> dev process on the app.
>
> I think the basics of the app should include:
>
> - Easy installer
> - User management
> - Application management
> - Webservices management
>
> Certain tasks that are currently handled in the hosting module of the
> eis intranet might also be worth integrating in some way either as stand
> alone or under app management (think database management).
>
> I think the focus for the configuration app "EIS COnfiguration MANager "
> (insert smiley here) should be the ability to roll out an app in just a
> few clicks.
>
> Well these were my 2 cents.
>
> Luuk
>
>
>
>   

[Eis-devel] 1.6 specs

[Luuk v. d. B. <luu...@en...>]

He all,

I don't have much to add to the 1.6 specs. They look good to me. I think
next we should start on the specs for the configuration app. These specs
should be made with in mind what 1.6 needs to be capable of rather than
what it's capable of now. Therefor I think these specs should be quite
rigid, so the work that needs to be done on 1.6 naturally flows from the
dev process on the app.

I think the basics of the app should include:

- Easy installer
- User management
- Application management
- Webservices management

Certain tasks that are currently handled in the hosting module of the
eis intranet might also be worth integrating in some way either as stand
alone or under app management (think database management).

I think the focus for the configuration app "EIS COnfiguration MANager "
(insert smiley here) should be the ability to roll out an app in just a
few clicks.

Well these were my 2 cents.

Luuk



-- 
*EntiQ BV*
/The Integration Company/

[Naam]

Postbus 86
6500 AB Nijmegen

W www.entiq.nl
E in...@en...

T +31 (0)24 360 6585
F +31 (0)24 360 9022
M +31 (0)6 [Mobiel nr]

[Eis-devel] EIS 1.6 specs draft finished

[Bas L. <ba...@ba...>]

Hey Guys,

first post on the developers mailinglist. whoohoo! :)
I finished a first draft of the 1.6 specs document. It is in the svn 
repos at /trunk_1.6/developer/docs/specs/specifications.odt
If you have any feedback feel free to let me know and I invite you to 
think about the "EIS manager" application we talked about. I have some 
ideas about this but I'd like to hear yours.
We can use this list for further discussion about the specs of both the 
manager app and EIS itself.

grtz,
Bas

PS
Please reply to this list in english. I would like to keep the list 
archives understandable for a broad audience.