Sounds great in theory, I'd be interested to see what the reality would look
like in OFBiz.
Regards
Scott
On 18/06/2013, at 8:51 AM, Ean Schuessler wrote:
> I don't know that I would say that. You could have a set of implementations
> that all map into a particular namespace and have different
I don't know that I would say that. You could have a set of implementations
that all map into a particular namespace and have different customers select
different combinations on a user by user basis. That flexibility would actually
let you run a larger set of customers on a single shared infras
Not really SaaS once you start heading down that road huh. Personally I'd focus
on designing for the 90% and if necessary, improving the framework to get
customizations for the 10% into the db.
Regards
Scott
On 18/06/2013, at 2:43 AM, Ean Schuessler wrote:
> Do you really want per-tenant hot-
Do you really want per-tenant hot-deploy directories?
- "Hans Bakker" wrote:
> Thanks Scott for you reply,
> perhaps not explained good, another try:
> Presently we can write:
> component://order/widget/order/..
> Would be nice if we could also write:
> component:/widget/ord
Surely you'd use one of the components as a base component and the other would
include the controller and re-reference the custom uris/views? But regardless,
I guess I understand what you're trying to do even if I don't understand why.
Anyway for a solution you'd want to create a new class that
Thanks Gil, I'm asking why not what. It doesn't make any sense to me why you'd
want to rename an existing component, it's difficult to do and I'm not sure of
the reason to try.
Regards
Scott
On 17/06/2013, at 8:22 PM, gil portenseigne wrote:
> Hi,
>
> I guess that Hans want to rename a duplic
Scott,
we currently ONLY develop components in hot-deploy which can be operated
in a SAAS multi tenant environment fr GrowERP.
In this multi tenant environment we have different customers using
similar components installed in the hot-deploy directory which need to
function at the same time f
Hi,
I guess that Hans want to rename a duplicated component of order. Then
with this new way to write the component://, it won't necessary to make
a global replacement of component://content by component://neworder in
the duplicated component.
Do the global replacement in the new component i
Thanks Hans.
I guess what I don't understand is why you would rename the OOTB component? It
seems like you're creating a headache for yourself unnecessarily.
Regards
Scott
On 17/06/2013, at 8:03 PM, Hans Bakker wrote:
> Thanks Scott for you reply,
>
> perhaps not explained good, another try
Thanks Scott for you reply,
perhaps not explained good, another try:
Presently we can write:
component://order/widget/order/..
Would be nice if we could also write:
component:/widget/order/..
which should be translated into:
component://order/widget/order/..
when the
What would the current component be once the screen/form (I assume you're
talking about screens/forms) was included from a different component? Would it
be local to the component it is defined in or local to the component it was
referenced from?
I can't really offer any alternative solutions b
The problem:
Sometimes we would like to demo similar components to different
customers on the same multi tenant installation.
The same problem will come up if we want to install it in a SAAS
environment.
Presently we can write:
component://order/widget/order/..
Would be nice if we co
12 matches
Mail list logo
