Re: Style tag for Widgets

[Taher Alkhateeb]

The widget system as I understand is a DSL for rendering user interfaces
regardless of the underlying technology. So HTML is only one output.

Introducing styles might create coupling between the widget system and
HTML. We have been working hard to completely disentangle web from widget
such as moving web artifacts from framework to common theme.

My suggestion for solving problems of custom elements includes the below:
- drop down to FTL using platform-specific tag
- design a new widget and call it something like  that we
can discuss its design in another thread.
- if something is commonly used, incorporate it into the framework.

So I would recommend avoiding the style attribute or limiting it to
specific tags.

On Jan 20, 2018 5:02 AM, "James Yong"  wrote:

> Hi all,
>
> Proposing a 

Style tag for Widgets

[James Yong]

Hi all,

Proposing a 

Re: [FYI] BuildBot current situation

[Jacques Le Roux]

I decided to for now close

 INFRA-15836     Buildbot sends repetitive success, or failure, reports

So the situation is clear, except if we get other repetitive emails of the same 
status.

Jacques



Le 16/01/2018 à 17:07, Jacques Le Roux a écrit :

Hi,

After recently
 INFRA-15785     OFBiz: remove R14 and R15, add R17
 INFRA-15829     OFBiz Buildbot tests don't pass, 8080 port error
 INFRA-15836     Buildbot sends repetitive success, or failure, reports,
 INFRA-15842     OFBiz Buildbot change the structure of tests logs
We have only
 INFRA-15836     Buildbot sends repetitive success, or failure, reports,
 INFRA-15842     OFBiz Buildbot change the structure of tests logs
open.

INFRA-15842 is trivial (just few logs dir to delete)
INFRA-15836 is a bit more annoying. We need to wait to see if this continues to happen and especially wait for feedback from the Infra team to see 
if it happens in other projects. We can also ask on HipChat if they forget to answer.


So we have a new BuildBot config which should be the basis after the framework 
and plugins splits and the R17 branch creation.

I'll complete the BuildBot doc, all comments are welcome...

Jacques


Le 13/01/2018 à 12:07, Jacques Le Roux a écrit :

I created INFRA-15836

Jacques


Le 13/01/2018 à 11:59, Jacques Le Roux a écrit :


This was intended to dev ML, at least the attachment passed

 Message transféré 
Sujet : Re: buildbot success in on ofbizTrunkFrameworkPlugins
Date : Sat, 13 Jan 2018 11:38:59 +0100
De : Jacques Le Roux 
Répondre à : dev@ofbiz.apache.org
Organisation : Les Arts Informatiques
Pour : comm...@ofbiz.apache.org

It seems it happened again (2 successful build messages, previous attached) 
when it's normally handled with INFRA-15394
But I think I know why. Those were triggered for different reasons:

Here

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkPluginsCommit' 
triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-plugins/trunk] 1821053
Blamelist: deepak

Previous

Build Reason: downstream
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1821039
Blamelist: jleroux

So Deepak committed directly to plugins and that actioned testIntegration (we 
can't test plugins changes else)
When I committed to trunk and that also actioned testIntegration to test for no 
regression in plugins (the plugins build is also dependent from the
trunk commit)

So we need to find a way to make those two cases same for OFBiz.

I'll open a request to Infra because the dependent solution was suggested and 
coded by Gavin and it's a bit over my BuildBot competences.
I'll thought check if I can't find a solution by myself and help is welcome

Jacques


Le 13/01/2018 à 10:08,build...@apache.org  a écrit :
> The Buildbot has detected a restored build on builder 
ofbizTrunkFrameworkPlugins while building . Full details are available at:
> https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/37
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: silvanus_ubuntu
>
> Build Reason: The AnyBranchScheduler scheduler named 'onTrunkPluginsCommit' 
triggered this build
> Build Source Stamp: [branch ofbiz/ofbiz-plugins/trunk] 1821053
> Blamelist: deepak
>
> Build succeeded!
>
> Sincerely,
>   -The Buildbot
>
>
>
>

Re: [Discussion] documentation framework for OFBiz

[Jacques Le Roux]

Hi Sharan, Craig,

We already have a document that consolidates many smaller documents into itself, but as said Sharan in another reply it got not much attention because 
it was maybe not statisfying (though had interesting info)


https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML

My 2cts

Jacques


Le 18/01/2018 à 13:31, Sharan Foga a écrit :

Hi Craig

Generally I was thinking about how it was going to be laid out. So if you think 
about one big consolidated OFBiz Guide that contains both technical and user 
guide info, then what would that look like? How would you structure the one 
consolidated output?

I don't think that it would necessarily need to mirror the exact structure of 
the menus - it just depends on how it's linked to the overall process (if you 
are thinking user docs). Also some of the things we need to write about won't 
appear anywhere in the menus - so we'll need a general place for that.

My comment was also about the format of each of the source documents to ensure 
consistency. Since we are going to be consolidating many smaller documents into 
one big one, so it needs to look like they belong together.

Hope that makes it clearer.

Thanks
Sharan

On 2018-01-17 16:08, Craig Parker  wrote:

I think the doc structure ought to mirror the menu in the software, or
are you talking about how a doc itself is laid out?


On 01/17/2018 09:25 AM, Sharan Foga wrote:

Hi Taher

Great work! I tried it out and found it simple and easy to use (and write!). 
When can we start writing ? :-)

I was thinking to start with basic descriptions of each of the applications, 
then see how it evolves from there. We can maybe recover some documentation 
content from various sources including our existing online help system and the 
wiki.

The documentation structure will maybe need some thought, and we may need to 
sort out some common template or guidelines around it.

Thanks
Sharan

On 2018-01-14 12:33, "Sharan Foga" wrote:

Excellent news Taher!

Thanks very much for your effort on this. I'll aim to try it out this week and 
come back with any feedback.

Thanks
Sharan

On 2018-01-12 17:36, Taher Alkhateeb  wrote:

Hello everyone,

Sorry for the delay on my part, I got a little preoccupied. Anyway, I
have a small patch in [1] that provides the PoC for integrating
asciidoctor with OFBiz. I also provided in the the JIRA [1]
instructions on how to run it. Essentially, this allows you to create
documentation for any component by simply creating a src/docs/asciidoc
directory and putting files inside.

This solution is flexible and allows us to build bigger designs on top
of it. Please review it and tell me if you like the general design.

[1] https://issues.apache.org/jira/browse/OFBIZ-9873

On Tue, Oct 17, 2017 at 11:01 AM, Taher Alkhateeb
 wrote:

Hello Folks,

We've had this discussion multiple times in the past, but I think I
have a more concrete idea this time for solving this problem. In the
past few weeks we've been working internally in Pythys to figure out
the best way to write and distribute documentation, and I think most
of that is applicable to OFBiz.

In a nutshell, here is the idea (practically) for how to proceed:

- The documentation language to use is Asciidoc
- The documentation tool is Asciidoctor
- Publishing happens through Gradle using the asciidoctor gradle
plugin (not the OFBiz framework or anything else).
- The only place where we write documentation is inside the code base
- Every component contains its own documentation
- General documentation goes to either a standalone directory or a
generic component like common or base
- As much as possible, documentation files are small and focused on
one topic. And then other longer documents are constructed from these
snippets of documentation.
- We publish to all formats including PDF for users, or HTML for
embedded help and wiki pages. So OFBiz does not parse docbook for its
help system, instead it just renders generated HTML.

As I've worked extensively with Asciidoc I find it easy to pickup
(like markdown) but also modular (like docbook and dita). It's also
neat that you can sprinkle variables all around in your document so
that update is no longer a painful grepping process.

Would love to hear your thoughts on this.

Cheers,

Taher Alkhateeb

Re: [Discussion] documentation framework for OFBiz

[Jacques Le Roux]

Inline...


Le 18/01/2018 à 13:54, Sharan Foga a écrit :

Hi Taher

I've included some comments inline.

On 2018-01-17 16:54, Taher Alkhateeb  wrote:

So I have thought of a few ways to implement our documentation
structure and I would like to share my ideas with everyone to see what
you prefer to go with. Here goes:

- First, let's categorize documentation as:
   - component-specific
   - general documentation

I like this as it is a simple and easy way for us to do our first split. In the 
past we have tried to put everything together in a way that doesn't really fit, 
so doing an initial is it this or that, makes it a lot easier.

+1


- component specific documentation lives inside the component in
"/src/docs/asciidoc". It is a self contained piece of documentation.
- Every component has only _one_ publishable document. There is a
methodology in asciidoctor to denote public and private documents.
private documents will not be published but only included in other
documents. This way we can make a modular documentation for each
component while publishing only one output.

I like the idea of only one publishable document per component. That means that 
we have a fixed scope for what the documentation needs to cover (so no 
documentation creep). I'm sure we will get interlinking between components so 
can plan for it and link when ready.

+1 and +1 for inter-links idea


- general documentation (i'm still scratching my head over this one)
could be placed maybe in framework/base. What it does is explain high
level information about the framework and explain general conceptual
principles of how things work.
I'm not sure this can be called general documentation. I was thinking at another place initially, one place where people should look intuitively, like 
a documentation sub-dir of root. But we need to define what we call general documentation.



- We can combine the entire documentation of everything (framework +
applications) in a single document that references all the other
documents and maybe we can place it at the top-level directory and
call it something like ofbiz-documentation.adoc

As long as people can easily navigate it and find what they want quickly then 
one document could be the solution. At least we can start with that and if does 
start to become too heavy then look at re-arranging it or splitting it up.
That sounds like a good idea, finding an ofbiz-documentation.adoc file is as easy as finding a documentation sub-dir of root. But then we need to 
remember that it's not often the content that confuse people but how to access it. So we need to think about the structure of this document (like 
separating end users and technical doc at the 1st level. Maybe we can think about having end users and technical doc separated in component?



In the past I think all the details from the online help were published as a 
consolidated html file via the OFBiz cms. I think it was too linked to the 
individual screens so as standalone document without the screens, it wasn't as 
useful as it could be.

I think people were also not much aware of this document, so it got not much 
critics and was not improved


- Plugins are not included in the full documentation, they are self
contained and are not part of the _big_ published manual. instead each
plugin has its own mini manual.
+1 on this. We will have to maintain the official plugin documentation, and I 
would see that people writing their own plugins can use this same mechanism to 
include their specific documentation.

Sure +1!





- We declare three gradle tasks similar to the below:
   - "./gradlew publishComponentDocs": publish documentation for a
specific component / plugin which requires a componentName flag.
   - "./gradlew publishAllComponentsDocs": publish documentation for
all components / plugins
   - "./gradlew publishOfbizDocs": publish the master documentation
manual that combines everything.


As per your later response, I think we could reduce the gradle tasks to one for 
the framework+core application docs and one for the plugins.

Thanks for sharing - you have some good ideas here.  Let's keep the discussion 
going :-) so anyone with other ideas, comments and feedback, please feel free 
to join the conversation.

I agree, let's continue to share :)

Jacques


Thanks
Sharan



This is a brain dump so I leave it to you fine folks to refine the
ideas and decide where we should go.

Cheers,

Taher Alkhateeb

On Wed, Jan 17, 2018 at 6:08 PM, Craig Parker  wrote:

I think the doc structure ought to mirror the menu in the software, or are
you talking about how a doc itself is laid out?



On 01/17/2018 09:25 AM, Sharan Foga wrote:

Hi Taher

Great work! I tried it out and found it simple and easy to use (and
write!). When can we start writing ? :-)

I was thinking to start with basic descriptions of each of the
applications, then see how it evolves from there. We can maybe recover some

Re: svn commit: r1813679 - in /ofbiz/ofbiz-framework/trunk: ./ framework/common/groovyScripts/ framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/

[Jacques Le Roux]

Hi Jinghai,

Actually both are accepted. I did not find a place where this is wrote, but you 
can try both work.

Anyway I changed at revision: 1821600

Jacques


Le 18/01/2018 à 06:49, Shi Jinghai a écrit :

Should it be "Authorization"? z, not s. If s is right for some specific environments, we can add an 
additional step to check "Authorisation" if getting "Authorization" header failed.

-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年1月16日 18:52
收件人: dev@ofbiz.apache.org
主题: Re: svn commit: r1813679 - in /ofbiz/ofbiz-framework/trunk: ./ 
framework/common/groovyScripts/ 
framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/

Thanks Deepak,

Ha indeed, I see your point now.

Sorry for the confusion!

Jacques


Le 16/01/2018 à 11:30, Deepak Dixit a écrit :

Thanks Jacques for detail,
but I think name is not always Authorisation in code we are having
lots of request.getHeader usage and its breaks their usage.
I'll confirm and reply here (just for reference.)

Need to backport this to 17.12 as well.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Tue, Jan 16, 2018 at 3:26 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 16/01/2018 à 09:53, Deepak Dixit a écrit :


+return super.getHeader("Authorisation");

I think this should be

return super.getHeader(name);


Thanks Deepak,

Actually let me explain the context here (maybe not for you but at
large) In the case of ExternalLoginKeysManager, it's always
"Authorisation". It's explained there
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorizati
on https://en.wikipedia.org/wiki/Basic_access_authentication
And it's the only usage of the wrapper so far.

Note that in the case of JWT token used in OAuth 2 you normally need
to use a bearer token
https://www.google.fr/search?q=http+authorization+header+bearer=UT
F-8 But in the case I committed it was not necessary (it's not OAuth
2, just a JWT token) and I must say I got issue trying to encode
things with it

Anyway you are right, why not using name there, it will not change
things, and the wrapper idea could be then reused/refactored when
adding other related features, will do :)

Jacques