Workspace Forms questions

Post any questions regarding Installing or Upgrading to V5, including problems starting and using the Ebase Server or Designer

Moderators: Jon, Steve, Ian, Dave

HarryDeBoer
Ebase User
Posts: 118
Joined: Tue Oct 23, 2012 7:01 am
Location: The Netherlands

Workspace Forms questions

#1

Postby HarryDeBoer » Mon Jul 20, 2015 7:59 am

1
what could be the benefit or downside for having multiple workspaces ? An explanation of the workspace concept would clear up things.

2
Lists, scripts etc. can have the same name in different projects. Forms however, can't. What's the reason of that and are there more entities which names must be unique?
0 x
Kind regards,

Harry

HarryDeBoer
Ebase User
Posts: 118
Joined: Tue Oct 23, 2012 7:01 am
Location: The Netherlands

#2

Postby HarryDeBoer » Mon Jul 20, 2015 9:34 am

Also:

>>Names of all elements throughout the system can now be entered in mixed case.

Form names however with names like
-Form1001
-form1001
-forM1001

will still trigger the 'aform with that name already exists' error. Even scripts, lists etc. gies the same error.

What's the exact point of allowing mixed case naming ?
0 x
Kind regards,

Harry

Steve James
Ebase User
Posts: 331
Joined: Mon Mar 10, 2014 8:34 am

#3

Postby Steve James » Mon Jul 20, 2015 11:16 am

I guess also a question would be.

How can I see what Workspace I am connected to when in the Designer?

I can tell when I start the Designer but I've not found any confirmation in the Designer anywhere.

Thanks
0 x

Jon
Moderator
Moderator
Posts: 1342
Joined: Wed Sep 12, 2007 12:49 pm

#4

Postby Jon » Tue Jul 21, 2015 7:52 am

Some answers..

1. What could be the benefit or downside for having multiple workspaces ?

It provides another way of dividing your work into different areas. For example if you're doing work for multiple customers, you might want to keep each customer's work in a separate workspace. This also makes more sense when using a source control system such as SVN or CVS. A workspace is pretty much equivalent to a repository database in V4. It will eventually be possible to switch the workspace used by the designer without a restart.

2. Lists, scripts etc. can have the same name in different projects. Forms however, can't. What's the reason of that and are there more entities which names must be unique?

Forms and workflow processes must have names which are unique within a workspace. The reason is that the URL used with V4 to start a form just provides the form name ..ufsmain?formid=MYFORM and this has to still work with V5. Similarly call form and workflow start job script commands just provide a form name or a process name.

3. Mixed case names

I think it's much nicer to allow mixed case names - the upper case names in V4 looked very clumsy. You can't mix names like Form1001, form1001, forM1001 in the same directory because some operating systems (Windows) don't support this i.e. they have case insensitive file systems. Linux does allow this, but we need also to consider the possibility that the OS might change.

4. How do I know which workspace I'm using?

Good question. We will provide this in the next V5 release.
0 x

HarryDeBoer
Ebase User
Posts: 118
Joined: Tue Oct 23, 2012 7:01 am
Location: The Netherlands

#5

Postby HarryDeBoer » Wed Jul 22, 2015 3:09 pm

[quote]Forms and workflow processes must have names which are unique within a workspace. The reason is that the URL used with V4 to start a form just provides the form name ..ufsmain?formid=MYFORM and this has to still work with V5.[/quote]

could that not have been solved with including the path:
..ufsmain?formid=PROJECT/MYFORM

it would so nice to have the same formname in different project (e.g index)

It is as is, I don't complain, just wondering :)
0 x
Kind regards,

Harry

Jon
Moderator
Moderator
Posts: 1342
Joined: Wed Sep 12, 2007 12:49 pm

#6

Postby Jon » Wed Jul 22, 2015 4:37 pm

We've tried this quite a few different ways. We've tried to avoid putting the project name into the url as this might cause problems when you wanted to move a form to another project i.e. you would have to change all the urls. We also tried the idea that all forms had an alias and this alias name had to be unique rather than the form name, but this caused its own problems and was generally confusing. So the current solution - form names have to be unique, same as in V4 - has been arrived at because we couldn't make any of the alternatives work successfully. Having said that, this story may not yet be finished.
0 x


Who is online

Users browsing this forum: No registered users and 3 guests