Adam, thanks again.
I didn't know about the contributors guide - I was always looking in the docs inside Nifi and there is a reference to the developer guide only. I will try to make a good processor for velocity first. The next step would then be to include also freemarker. I will try to keep that in mind during design and coding. I don't know anything about Markdown or Asciidoc. So I will have to have a look first. Regards, Uwe > Gesendet: Freitag, 18. März 2016 um 18:58 Uhr > Von: "Adam Taft" <a...@adamtaft.com> > An: dev@nifi.apache.org > Betreff: Re: Processor: User friendly vs system friendly design > > Uwe, > > The Developer Guide[1] and Contributor Guide[2] are pretty solid. The > Developer Guide has a section dealing with reading & writing flowfile > attributes. Please check these out, and then if you have any specific > questions, please feel free to reply. > > For inclusion in NIFI directly, you'd want to create a NIFI Jira ticket > mentioning the new feature, and then fork the NIFI project in Github and > send a Pull Request referencing the ticket. However, if you just want some > feedback on suitability and consideration for inclusion, using your own > personal Github project and sending a link would be fine. > > Having a template conversion processor would be a nice addition. Making it > generic to support Velocity, FreeMarker, and others might be really nice. > Extra bonus points for Markdown or Asciidoc transforms as well (but these > might be too separate of a use case). > > Hope this helps. > > Adam > > [1] http://nifi.apache.org/developer-guide.html > > [2] https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide > > > > > On Fri, Mar 18, 2016 at 1:36 PM, Uwe Geercken <uwe.geerc...@web.de> wrote: > > > Adam, > > > > interesting and I agree. that sounds very good. > > > > can you give me short tip of how to access attributes from code? > > > > once I have something usable or for testing where would I publish it? just > > on my github site? or is there a place for sharing? > > > > greetings > > > > Uwe > > > > > > > > Gesendet: Freitag, 18. März 2016 um 18:03 Uhr > > Von: "Adam Taft" <a...@adamtaft.com> > > An: dev@nifi.apache.org > > Betreff: Re: Processor: User friendly vs system friendly design > > I'm probably on the far end of favoring composibility and processor reuse. > > In this case, I would even go one step further and suggest that you're > > talking about three separate operations: > > > > 1. Split a multi-line CSV input file into individual single line flowfiles. > > 2. Read columns from a single CSV line into flowfile attributes. > > 3. Pass flowfile attributes into the Velocity transform processor. > > > > The point here, have you considered driving your Velocity template > > transform using flowfile attributes as opposed to CSV? Flowfile attributes > > are NIFI's lowest common data representation, many many processors create > > attributes which would enable your Velocity processor to be used by more > > than just CSV input. > > > > Adam > > > > > > > > On Fri, Mar 18, 2016 at 11:06 AM, Uwe Geercken <uwe.geerc...@web.de> > > wrote: > > > > > > > > Hello, > > > > > > my first mailing here. I am a Java developer, using Apache Velocity, > > > Drill, Tomcat, Ant, Pentaho ETL, MongoDb, Mysql and more and I am very > > much > > > a data guy. > > > > > > I have used Nifi for a while now and started yesterday of coding my first > > > processor. I basically do it to widen my knowledge and learn something > > new. > > > > > > I started with the idea of combining Apache Velocity - a template engine > > - > > > with Nifi. So in comes a CSV file, it gets merged with a template > > > containing formatting information and some placeholders (and some limited > > > logic maybe) and out comes a new set of data, formatted differently. So > > it > > > separates the processing logic from the formatting. One could create > > HTML, > > > XML, Json or other text based formats from it. Easy to use and very > > > efficient. > > > > > > Now my question is: Should I rather implement the logic this way that I > > > process a whole CSV file - which usually has multiple lines? That would > > be > > > good for the user as he or she has to deal with only one processor doing > > > the work. But the logic would be more specialized. > > > > > > The other way around, I could code the processor to handle one row of the > > > CSV file and the user will have to come up with a flow that divides the > > CSV > > > file into multiple flowfiles before my processor can be used. That is not > > > so specialized but it requires more preparation work from the user. > > > > > > I tend to go the second way. Also because there is already a processor > > > that will split a file into multiple flowfiles. But I wanted to hear your > > > opinion of what is the best way to go. Do you have a recommendation for > > me? > > > (Maybe the answer is to do both?!) > > > > > > Thanks for sharing your thoughts. > > > > > > Uwe > > > > > >
