Re: Clarification on converter concept
Joerg Heinicke skrev: On 14.07.2007 15:55, Daniel Fagerstrom wrote: ... Doesn't this variant selection go very much into the direction of assumption about the data type? It is up to the user. The user could as an example have a "short" variant for the short form of a couple of different data types. This argument is a bit lousy, isn't it? ;-) I don't see that an assumption about what kind of concept you are accessing should be a problem, but we should definitively avoid low level assumptions. As an example: I don't see any problem with letting the template author knowing that something is a date, and optionally make it possible to chose between different visual presentations. But the template author should not need to be aware about differences between java.sql.Date, java.util.Date and a custom date type. It also completely decouples the object-to-string conversion from the templating while with the "select a variant"-approach in the template the conversion can not be done without the template. That is an implementation detail. We have an object model that an expression language can be applied on where the result in turn can be converted by a converter and the result in turn can be used in a template. We have 4 different parts that can be used both together and in parts if implemented in the right way. For me it's 1. object model, 2. object-to-string conversion and 3. referencing the value in the template via the EL. If the EL influences the conversion 2. and 3. are coupled. That's not just an implementation detail. No, the object to string conversion is done on the result from the EL, not the other way around. The "#variant" is not part of the EL, it is part of a separate "converter language". ... /Daniel
Re: Clarification on converter concept
Joerg Heinicke wrote: > Issue 3 to hand in there :) :) > Ok, I just did not found anything about the bean map. And compared the > number of classes (20+) with the number of pages regarding functionality > (4: running modes, property handling, bean configuration, log4j). Maybe > I jumped the conclusions :-) They main topics seem indeed to be covered, > only (?) bean map docs are missing. Ah, great, yes bean map has been added later - I'll document it in the next days. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Clarification on converter concept
On 16.07.2007 02:48, Carsten Ziegeler wrote: Hmm, was the first time I had a look into it today. Really? :) Unfortunately :( So if anyone thinks that it makes sense to promote this stuff "somewhere", let's do it :) Issue 3 to hand in there :) For the latter it would be good to have documented what's there and how it is supposed to be used. The documentation at Daisy is a bit spare. Hmm, I haven't looked at the docs recently, but I thought i had documented everything which is in it. Ok, I just did not found anything about the bean map. And compared the number of classes (20+) with the number of pages regarding functionality (4: running modes, property handling, bean configuration, log4j). Maybe I jumped the conclusions :-) They main topics seem indeed to be covered, only (?) bean map docs are missing. Joerg
Re: Clarification on converter concept
On 16.07.2007 04:58, Daniel Fagerstrom wrote: Actually I'm not very keen on any templating approach at all. I prefer a push approach as well. But this project is not about creating the ideal template framework. You digress :-) I did not want to get into this discussion about the best approach at all. I only wanted to point out that there are different approaches to do things, where you don't have an EL available, so where variants can't be used. That's why I'd like to see at least a combined path/variant approach instead of a variant-only approach. OTOH switching to a path-only approach seems also not possible since this can't handle all use cases as you outlined with the multiple date representations. Joerg
Re: Clarification on converter concept
On 15.07.2007 00:45, Vadim Gritsenko wrote: I also wonder how you are going to use CForms without CTemplate? You must use some template mechanism to produce data representing form and its state. FormsTransformer? It has a template approach as well [1], but no EL at all. FormsTransformer is sort of on its way out (right, Jeremy?) It was only an example for independent usage of either CForms or CTemplate. It is also possible to not use CForms, but just some plain simple form. When you use a converter here you somehow need to get the value converted back as well. With Spring I can do this, I'm not tied to use their taglib since the converter wraps the object. Actually I'm not very keen on any templating approach at all. FormsGenerator? I'm aware of it. Again it was just an example of independent usage. Joerg
Re: Clarification on converter concept
On 14.07.2007 15:55, Daniel Fagerstrom wrote: The main difference in my view is that with paths the choice of presentation is connected to the model and with anchors it is connected to the presentation. Ok, I agree. Both cases have legitimate uses. A particular date could be presented both in its short form in a table and in its long form in a text. That is clearly a presentation issue. I'd really like to involve Spring guys here. I'm interested how they think this can be solved. Doesn't this variant selection go very much into the direction of assumption about the data type? It is up to the user. The user could as an example have a "short" variant for the short form of a couple of different data types. This argument is a bit lousy, isn't it? ;-) It also completely decouples the object-to-string conversion from the templating while with the "select a variant"-approach in the template the conversion can not be done without the template. That is an implementation detail. We have an object model that an expression language can be applied on where the result in turn can be converted by a converter and the result in turn can be used in a template. We have 4 different parts that can be used both together and in parts if implemented in the right way. For me it's 1. object model, 2. object-to-string conversion and 3. referencing the value in the template via the EL. If the EL influences the conversion 2. and 3. are coupled. That's not just an implementation detail. Further, using an EL and format variants on a bean model would probably be possible for a web designer. Writing Spring bean configurations seem to be a little bit to much. I agree that the different date representations are presentation issues, not model issue. I don't have any solution for it except those variants. Also if you have e.g. a regexp defined format, will you need to repeat it for each property path you would like to apply it on? You don't need to. Similar to the setup of the "short" variant you can set up the regexp-defined editor. You only would need to reference it multiple times in the bean definition as shown with my MapBasedPropertyEditorRegistrar sample [1]. That's similar to referencing "short" in the EL. There is indeed no way to select a converter based on the locale at the moment. To me this sounds like Spring doesn't have a satisfying solution to the locale problem right now. Didn't I confirm this already? :-) That's the second thing I'd like to get Spring community involved. Joerg [1] http://marc.info/?l=xml-cocoon-dev&m=118438238711044&w=4
Re: Clarification on converter concept
Daniel Fagerstrom pisze: Joerg Heinicke skrev: On 13.07.2007 10:31, Grzegorz Kossakowski wrote: ... Actually I'm not very keen on any templating approach at all. I don't like to first provide data to some template context and second retrieve it from there in the template. IMO it's much better to have a complete push approach and only encroach if it is necessary (like XSLT templates). (My diploma thesis was about this btw.) I prefer a push approach as well. But this project is not about creating the ideal template framework. It is about keeping back compatibility and at the same time giving users a simpler and cleaner way forward for new development and possible refactoring of old stuff. Yes, I think Daniel is right about my goal. AFAIU, it will be possible to use the object model without any default content, (is that true Grzegorz?). In such a scenario you can have a pure push approach, by only pushing the data that should be rendered into the object model. Yes, there will be default ObjectModel implementation that will collect environmental data and expose in unified way but you can easily write your own implementation (it will have very light-weight interface) that could expose any data you like and any form you like. It's a worth to say that thanks to Spring Configurator capabilities it will be extremely easy to force any our component to use your own ObjectModel implementation. I preferred that kind of solution once. But now I find it unnecessary complicated in most cases. The first problem is that it requires some work to convert bean structure to XML data. You will probably need some configuration file that handle part of the conversion. In comparison to just applying an EL to a bean structure it is more complicated. Second, many people find XSLT much more complicated than a simple template language. Third, the development of XSLT processors and tooling, has been a disappointment. Xalan, still doesn't implement XSLT 2.0, and the error messages from both Xalan and Saxon can often be cryptic or non existent. Same feelings here, unfortunately (I find XSLT really nice as idea). -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Joerg Heinicke skrev: On 13.07.2007 10:31, Grzegorz Kossakowski wrote: ... Actually I'm not very keen on any templating approach at all. I don't like to first provide data to some template context and second retrieve it from there in the template. IMO it's much better to have a complete push approach and only encroach if it is necessary (like XSLT templates). (My diploma thesis was about this btw.) I prefer a push approach as well. But this project is not about creating the ideal template framework. It is about keeping back compatibility and at the same time giving users a simpler and cleaner way forward for new development and possible refactoring of old stuff. AFAIU, it will be possible to use the object model without any default content, (is that true Grzegorz?). In such a scenario you can have a pure push approach, by only pushing the data that should be rendered into the object model. A possible implementation for this is to convert the form model into an XML representation Not everything is in forms. We need a mechanism for rendering model data without connecting it to a form. and let a quite generic XSLT do the rest. With this approach no EL come into play. This also means there is a separate object-to-string step. I preferred that kind of solution once. But now I find it unnecessary complicated in most cases. The first problem is that it requires some work to convert bean structure to XML data. You will probably need some configuration file that handle part of the conversion. In comparison to just applying an EL to a bean structure it is more complicated. Second, many people find XSLT much more complicated than a simple template language. Third, the development of XSLT processors and tooling, has been a disappointment. Xalan, still doesn't implement XSLT 2.0, and the error messages from both Xalan and Saxon can often be cryptic or non existent. In the end XSLT has its uses, but for simple rendering of beans I find simple template languages like JXTG much more productive (and I have written tons of XSLT). /Daniel
Re: Clarification on converter concept
Joerg Heinicke wrote: >> Spring configurator stuff is really handy and has no Cocoon >> dependencies so its wise to use it. Joerg, you seem to sit inside >> Spring community, have you considered giving Carsten a present by >> promoting his stuff? I really think it should get more attention. :-) > > Hmm, was the first time I had a look into it today. Really? :) > I can't say if this > all is of general use. Do you think of moving this stuff or parts of it > to Spring (that would be actually up to Carsten IMO) or just get more > users to it? The spring configurator is imho of general use and I built it with this in mind as I removed most of the Cocoon specific stuff - apart from the package names there are no dependencies to cocoon (or any other 3rd party libs) and we used it a lot outside of Cocoon. It provides many nice features when you work with Spring. So, yes the genreal idea was to move it to a broader place. It would be cool to have it "nearer to Spring", but I personally don't have the time/energy to do this right now. I had the hope that with a release of 2.2 there woudl be many interested people who find the configurator handy which then leads to a larger community around the project etc. - but, well... So if anyone thinks that it makes sense to promote this stuff "somewhere", let's do it :) > For the latter it would be good to have documented what's > there and how it is supposed to be used. The documentation at Daisy is a > bit spare. Hmm, I haven't looked at the docs recently, but I thought i had documented everything which is in it. It might be that the latest features are not documented. I'll have a look at it in the next days. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Clarification on converter concept
Daniel Fagerstrom wrote: ... A particular date could be presented both in its short form in a table and in its long form in a text. That is clearly a presentation issue. A specific double in a model should normally not represent both a percentage, a currency amount and a scientific value, what it represents is clearly a model issue. This particular double, *can* potentially have multiple representations (even on the same page). Example - 2 and 4 positions after the dot: 0.11 and 0.; negative with '-' or negative in parenthesis '()': -123 and (123); with leading 0 or without: .123 and 0.123; scientific representation; etc. So I'd say double in no way different from date. Vadim
Re: Clarification on converter concept
Joerg Heinicke wrote: On 13.07.2007 10:31, Grzegorz Kossakowski wrote: I also wonder how you are going to use CForms without CTemplate? You must use some template mechanism to produce data representing form and its state. FormsTransformer? It has a template approach as well [1], but no EL at all. FormsTransformer is sort of on its way out (right, Jeremy?) Actually I'm not very keen on any templating approach at all. I don't like to first provide data to some template context and second retrieve it from there in the template. IMO it's much better to have a complete push approach and only encroach if it is necessary (like XSLT templates). (My diploma thesis was about this btw.) A possible implementation for this is to convert the form model into an XML representation and let a quite generic XSLT do the rest. FormsGenerator? http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/forms/generation/FormsGenerator.html Vadim
Re: Clarification on converter concept
Joerg Heinicke skrev: On 07.07.2007 11:16, Daniel Fagerstrom wrote: ... The form infrastructure creates two property paths from the id. One for accessing the start date from the form object to insert in the generated html page. And one property path is used as content of the name attribute in the generated html form element. Can't quite follow. Isn't that supposed to be the same one? I mean when the path is used as form field's name it ends as request parameter name. That one needs to be used to bind the value to the form object correctly. What I meant is that the property path is of course the same for both read and write access, but its representation is different in CForms for the both cases. For reading it is doesn't have any explicit form but is only implicitly represented in the tag structure for a CForm. For write access it has the mentioned (e.g. "tasks.2.startDate") form in the name attribute of the generated html form tag. ... And actually we are back to the Spring way using the path, aren't we? There is only the minor difference of using the full path vs. the anchor. The anchor adds additional flexibility since it can be specified in contrary to the generated path. The main difference in my view is that with paths the choice of presentation is connected to the model and with anchors it is connected to the presentation. Both cases have legitimate uses. A particular date could be presented both in its short form in a table and in its long form in a text. That is clearly a presentation issue. A specific double in a model should normally not represent both a percentage, a currency amount and a scientific value, what it represents is clearly a model issue. And we are probably only having one presentation for each representation, so the path idea is better in this case. From a OO purist POV, there should be own classes for currency amounts, percentages and so on, so we wouldn't have to care about variant representations at all in this case. But as Java isn't a pure OO language, such a purist view isn't practically feasible, we need variants in this case as well. I only really don't know if that flexibility is good. I mean you talked about scattered locale handling. This solution now tends to scattered variant handling IMO. I also don't know how it conforms with Parr's requirements for a template language. Doesn't this variant selection go very much into the direction of assumption about the data type? It is up to the user. The user could as an example have a "short" variant for the short form of a couple of different data types. I can live with this concept but actually I prefer the path stuff of Spring much more since this is completely transparent to the template. In the date case where there are several different presentations of the same concept it is part of the presentation concern and shouldn't be separated from the template. It also completely decouples the object-to-string conversion from the templating while with the "select a variant"-approach in the template the conversion can not be done without the template. That is an implementation detail. We have an object model that an expression language can be applied on where the result in turn can be converted by a converter and the result in turn can be used in a template. We have 4 different parts that can be used both together and in parts if implemented in the right way. The question is what we lose when refraining from the variant: Only the possibility to use one property of the object twice in a template and format it differently. That is an important thing that we would lose. As described above we would lose the ability to chose between different presentations in the view. Further, using an EL and format variants on a bean model would probably be possible for a web designer. Writing Spring bean configurations seem to be a little bit to much. Also if you have e.g. a regexp defined format, will you need to repeat it for each property path you would like to apply it on? Anything else is addressed in Spring. So you can register form-specific converters. That's also how I handle it when I register converters for a particular path. In contrary type-specific converters are registered globally. (Where "globally" is not quite correct since the converters are prototypes anyway. The registration is a topic on its own below.) The property path could be used to determine the variant instead of specifying it explicitly. It's obviously not that flexible - but can't be broken in that way. That's why I would opt for class, locale and path, so add locale to Spring's PropertyEditorRegistry methods. It would be like having id selectors but not class selectors in CSS. I think this comparison is misleading. Class selectors in CSS was the inspiration for the variants. IMO path and variant are really similar concepts. It's only the way where/how they were specifi
Re: Clarification on converter concept
On 13.07.2007 17:06, Grzegorz Kossakowski wrote: How your MapBasedPropertyEditorRegistrar knows path at which particular editor should be registered? Hmm, that's indeed getting a problem. Not with the MapBasedPropertyEditorRegistrar itself, it handles nested maps. The key of the first map is the data type, the key of the second one the path. This needs to get flattened on PropertyEditorRegistrar.registerCustomEditors(PropertyEditorRegistry) to match PropertyEditorRegistry.registerCustomEditor(Class type, String path, PropertyEditor editor). It now gets a problem since there seems to be no obvious way to automatically register editors with path - except some more complex way of (mis)using the bean's name. Hmm, what about (adapting the EL registry way): with both path and variant being optional. This still lacks the registering for our third criteria, the locale. So I wonder if we don't need a different style of registering anyway. Spring configurator stuff is really handy and has no Cocoon dependencies so its wise to use it. Joerg, you seem to sit inside Spring community, have you considered giving Carsten a present by promoting his stuff? I really think it should get more attention. :-) Hmm, was the first time I had a look into it today. I can't say if this all is of general use. Do you think of moving this stuff or parts of it to Spring (that would be actually up to Carsten IMO) or just get more users to it? For the latter it would be good to have documented what's there and how it is supposed to be used. The documentation at Daisy is a bit spare. Joerg
Re: Clarification on converter concept
On 13.07.2007 10:31, Grzegorz Kossakowski wrote: In a state full scenario we are keeping the form object in e.g. a session, so the form template generator could store the associations between property paths and formating variants in the form object as well. Doesn't that tie both CForms and CTemplate together? My understanding is that this approach ties CForms to EL and CTemplate to EL so EL functionality becomes a bridge for two way communication. This is indeed more exact. I considered EL being part of CTemplate :-) I also wonder how you are going to use CForms without CTemplate? You must use some template mechanism to produce data representing form and its state. FormsTransformer? It has a template approach as well [1], but no EL at all. Actually I'm not very keen on any templating approach at all. I don't like to first provide data to some template context and second retrieve it from there in the template. IMO it's much better to have a complete push approach and only encroach if it is necessary (like XSLT templates). (My diploma thesis was about this btw.) A possible implementation for this is to convert the form model into an XML representation and let a quite generic XSLT do the rest. With this approach no EL come into play. This also means there is a separate object-to-string step. In a stateless scenario, we could instead store the assoications in the form page. IMO it should always work this way, not like the above one for stateful form-processing. This would make whole processing easier to follow, wouldn't it? Difference should not be that big since it's more an implementation detail than something that should concern the user. My main reasoning was the decoupling of EL and CForms. And actually we are back to the Spring way using the path, aren't we? There is only the minor difference of using the full path vs. the anchor. The anchor adds additional flexibility since it can be specified in contrary to the generated path. My impression is that there is a more serious difference between the concepts. While using Daniel's approach you attach converter to the certain path by choosing its variant when you actually pull the data. It doesn't matter if you pull it in form model or template. Spring approach is about attaching everything in advance. That's true. It's the controller that decides which converters get applied, not the view. The "minor difference" I talked about was from the registry POV. Something is just asking for a converter, the only difference is the string which is used for retrieving the converter then. Then it turns out that Daniel's proposal is about registering several converters for every possible path and use variant to choose one from the list (if default is not satisfying). Since, it's all about registering for every possible path (assuming that there is suitable converter for each object) and registering more than one converter it's conceptually different from Spring's approach. Hmm, not really. Even with the current default implementation you can register multiple converters per path differing in the type. You just add another criteria. What's different is the more complex understanding of "path" since you might include the variant in it. Seems to be only a matter of registry implementation how it stores and finds converters. I hope that paragraph didn't confuse things even more... I needed to read it twice but I think I got the message :-) So how far are we from an overall agreement and Grek implementing this for us ;-) I would happy to do it, but I'd be very grateful if we come with strong and detailed agreement. I didn't want to put any pressure on you ;-) Just wondered what the open issues are we still have. Joerg [1] http://cocoon.apache.org/2.1/userdocs/publishing/templating.html
Re: Clarification on converter concept
Joerg Heinicke pisze: Grzegorz Kossakowski apache.org> writes: I mentioned that snippet as an example how registry could work; my aim was to show that we use declarative approach instead of registering converters/ property editors manually. Ah, got it. :-) Though the names are a bit irritating. Aren't the ExpressionCompilers actually the factories and isn't the ExpressionFactory more of a registry? It's also a bit strange that the Expressions must be aware of the prefix they are mapped to (Expression.getLanguage() + constructors of implementations). Any reason for that? Good point about names. I'll consider to rename this classes since I don't consider them as any public API (it was used in template block only to date). When it comes to prefix and getLanguage() method, I don't know really. Eclipse tells me that this method is not us anywhere in Cocoon so I think it redundant. Before removing it I'll try to search archives. This stuff is really work in progress and comes as legacy so I don't know answers for all questions... Something similar exists for the PropertyEditors, the PropertyEditorRegistrar [1]. You are only supposed to implement it yourself which more or less means to add the PropertyEditors programmatically. Since I did not want to do this, I wrote a MapBasedPropertyEditorRegistrar (matching more or less DefaultExpressionFactory) which I could at least configure from Spring. spring-configurator's BeanMap seems to go one step further and searches for all implementations of a particular interface in the application context. How your MapBasedPropertyEditorRegistrar knows path at which particular editor should be registered? Spring configurator stuff is really handy and has no Cocoon dependencies so its wise to use it. Joerg, you seem to sit inside Spring community, have you considered giving Carsten a present by promoting his stuff? I really think it should get more attention. :-) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Grzegorz Kossakowski apache.org> writes: > >> Yes, there is still a registry but neither EL user nor EL > >> implementation must care about it. > > > > This looks like a registry for expression languages, not for converters. > > How is it related? > > I mentioned that snippet as an example how registry could work; my aim was to > show that we use declarative approach instead of registering converters/ > property editors manually. Ah, got it. :-) Though the names are a bit irritating. Aren't the ExpressionCompilers actually the factories and isn't the ExpressionFactory more of a registry? It's also a bit strange that the Expressions must be aware of the prefix they are mapped to (Expression.getLanguage() + constructors of implementations). Any reason for that? Something similar exists for the PropertyEditors, the PropertyEditorRegistrar [1]. You are only supposed to implement it yourself which more or less means to add the PropertyEditors programmatically. Since I did not want to do this, I wrote a MapBasedPropertyEditorRegistrar (matching more or less DefaultExpressionFactory) which I could at least configure from Spring. spring-configurator's BeanMap seems to go one step further and searches for all implementations of a particular interface in the application context. Joerg [1] http://static.springframework.org/spring/docs/2.0.x/api/ org/springframework/beans/PropertyEditorRegistrar.html
Re: Clarification on converter concept
Joerg Heinicke pisze: In a state full scenario we are keeping the form object in e.g. a session, so the form template generator could store the associations between property paths and formating variants in the form object as well. These associations are then available to use when parsing the input from the post. And we can make sure that the right variant of the converter is used. Doesn't that tie both CForms and CTemplate together? Imagine using only one of both - which would break the concept. My understanding is that this approach ties CForms to EL and CTemplate to EL so EL functionality becomes a bridge for two way communication. I also wonder how you are going to use CForms without CTemplate? You must use some template mechanism to produce data representing form and its state. In a stateless scenario, we could instead store the assoications in the form page. We could e.g. add it to the property path in the name attribute: "tasks.2.startDate#short". Then the post parser can use the variant info for choosing the right converter. That's an interesting approach. IMO it should always work this way, not like the above one for stateful form-processing. Same feelings here. This would make whole processing easier to follow, wouldn't it? And actually we are back to the Spring way using the path, aren't we? There is only the minor difference of using the full path vs. the anchor. The anchor adds additional flexibility since it can be specified in contrary to the generated path. My impression is that there is a more serious difference between the concepts. While using Daniel's approach you attach converter to the certain path by choosing its variant when you actually pull the data. It doesn't matter if you pull it in form model or template. Spring approach is about attaching everything in advance. I only really don't know if that flexibility is good. I mean you talked about scattered locale handling. This solution now tends to scattered variant handling IMO. I also don't know how it conforms with Parr's requirements for a template language. Doesn't this variant selection go very much into the direction of assumption about the data type? I can live with this concept but actually I prefer the path stuff of Spring much more since this is completely transparent to the template. It also completely decouples the object-to-string conversion from the templating while with the "select a variant"-approach in the template the conversion can not be done without the template. Both are good points. I would be very interested in Daniel's response... It would be like having id selectors but not class selectors in CSS. I think this comparison is misleading. IMO path and variant are really similar concepts. It's only the way where/how they were specified and so the converter is selected. I support Daniel's view. You can apply certain variant to several different paths. Actually, the point is that we could treat Daniel's proposal in Spring terms. Then it turns out that Daniel's proposal is about registering several converters for every possible path and use variant to choose one from the list (if default is not satisfying). Since, it's all about registering for every possible path (assuming that there is suitable converter for each object) and registering more than one converter it's conceptually different from Spring's approach. I hope that paragraph didn't confuse things even more... The new approach using PropertyEditorRegistrar externalizes this into another component. But that one has no access to the request information and so can not even create locale-specific converters. What I know asked myself: How I am supposed to do this at all with Spring? I will file an issue at Spring's Jira requesting an improvement about a locale-aware registry. My hope is that this might get fixed for Spring 2.1 since I consider this really important and generic enough to be of use in Spring in general. Then we do not even need to modify/ replace this part of Spring's converter infrastructure. Otherwise I would reuse as much as possible of this infrastructure though. It's only the registry part that needs modification/ replacement. Therefore dropping the complete infrastructure does not make much sense IMO. So how far are we from an overall agreement and Grek implementing this for us ;-) I would happy to do it, but I'd be very grateful if we come with strong and detailed agreement. I started to implement Object Model several days ago without detailed vision and the whole development turned out to be fairly painful because I found hard to design something that covers so broad subject like universal Object Model usable for whole Cocoon. I hope it will be easier with converters because all this struggle scared me a little bit. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Joerg Heinicke pisze: On 10.07.2007 10:30, Grzegorz Kossakowski wrote: It will be bean's ID pointing that this particular bean implements "short" variant. We use powerful Spring configurator[1] stuff for doing the trick, see this[2] for an example: class="org.apache.cocoon.components.expression.DefaultExpressionFactory"> type="org.apache.cocoon.components.expression.ExpressionCompiler"/> The expressionCompilers property is a Map. Yes, there is still a registry but neither EL user nor EL implementation must care about it. This looks like a registry for expression languages, not for converters. How is it related? I mentioned that snippet as an example how registry could work; my aim was to show that we use declarative approach instead of registering converters/property editors manually. Can you please elaborate on this and add it to this other branch why actually? Maybe there is a different understanding which lead to different impressions on this. Ok, I'll do it. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Joerg Heinicke pisze: What about map: language we have discussed earlier? How is it related? Or does map: mean something different here than the default sitemap language namespace prefix? Yes, it means something different, see: http://article.gmane.org/gmane.text.xml.cocoon.devel/73700 http://article.gmane.org/gmane.text.xml.cocoon.devel/73760 I've brought map expression language back to discussion to show that we effectively need more than one EL. Getting back to the earth, are you sure that all browsers will be happy with # character in field's name? HTML spec nearly makes no restrictions for name attribute, it's declared as CDATA [1, 2]. [2] though mentions explicitly ID and *NAME* tokens which are defined quite restrictive, so that's a bit confusing. Spring MVC also generates names like object.collection[3].property instead of CForms object.collection.3.property. Being declared as CDATA I wonder what the browsers do with an = in a form field's name. Anyway we should not only have name but also id in mind [3]. Not much is allowed for them [4]. Except some rather obscure "combining chars" and "extenders" only '.', '-', '_' and ':'. So the last one might be the best choice. Thanks for analysis. It seems that Daniel's proposal is even possible to implement, good to know. :-) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
On 10.07.2007 10:30, Grzegorz Kossakowski wrote: What do you mean by registering? Where does the template know from which converter to apply? That's defined by a particular converter which can be looked up by the template in the registry. It will be bean's ID pointing that this particular bean implements "short" variant. We use powerful Spring configurator[1] stuff for doing the trick, see this[2] for an example: class="org.apache.cocoon.components.expression.DefaultExpressionFactory"> type="org.apache.cocoon.components.expression.ExpressionCompiler"/> The expressionCompilers property is a Map. Yes, there is still a registry but neither EL user nor EL implementation must care about it. This looks like a registry for expression languages, not for converters. How is it related? Could you elaborate on the "impedance mismatch"? I would like to see concrete examples to know what you mean. I'm curious because I used to really like JXPath. I stole this term from O2R mapping where it is known that there is no 1:1-mapping between the concepts. I remember having a similar problem with working with XPath on objects, especially collections. I thought this was even documented in the official documentation [1] but I can't find it from a quick look. So drop this. Now I get your point, and understand your arguments. However, as we seen already Daniel proposed very neat solution. Let's continue this discussion on the other branch of this thread. As for now I much prefer such solution because playing with registries keeping PropertyEditors attached to some paths is not the most elegant solution, IMHO. Can you please elaborate on this and add it to this other branch why actually? Maybe there is a different understanding which lead to different impressions on this. This mail helped a lot not only to understand your stand but to bring issues that I have not been thinking about before. Good to hear :-) Joerg [1] http://jakarta.apache.org/commons/jxpath/users-guide.html
Re: Clarification on converter concept
On 08.07.2007 06:34, Grzegorz Kossakowski wrote: Just to clarify: I would much have preferred if we only had one expression language (EL) in Cocoon and a property style syntax like the Spring one or JEXL would be fine with me. This is the main motivation for the plugable EL architecture. What about map: language we have discussed earlier? How is it related? Or does map: mean something different here than the default sitemap language namespace prefix? Getting back to the earth, are you sure that all browsers will be happy with # character in field's name? HTML spec nearly makes no restrictions for name attribute, it's declared as CDATA [1, 2]. [2] though mentions explicitly ID and *NAME* tokens which are defined quite restrictive, so that's a bit confusing. Spring MVC also generates names like object.collection[3].property instead of CForms object.collection.3.property. Being declared as CDATA I wonder what the browsers do with an = in a form field's name. Anyway we should not only have name but also id in mind [3]. Not much is allowed for them [4]. Except some rather obscure "combining chars" and "extenders" only '.', '-', '_' and ':'. So the last one might be the best choice. Joerg [1] http://www.w3.org/TR/html401/interact/forms.html#h-17.4 [2] http://www.w3.org/TR/html401/types.html#h-6.2 [3] http://www.w3.org/TR/2006/REC-xml-20060816/#id [4] http://www.w3.org/TR/2006/REC-xml-20060816/#NT-NameChar
Re: Clarification on converter concept
On 07.07.2007 11:16, Daniel Fagerstrom wrote: As I wrote repeatedly the possibility to influence the formatting from the template breaks the two-way process. First, from a separation of concern POV, it is IMO much preferable to influence the formating variant, both for output and input, in the form template. Second, we have the question if it is possible to accomplish ;) Yes, I think it is. The form infrastructure creates two property paths from the id. One for accessing the start date from the form object to insert in the generated html page. And one property path is used as content of the name attribute in the generated html form element. Can't quite follow. Isn't that supposed to be the same one? I mean when the path is used as form field's name it ends as request parameter name. That one needs to be used to bind the value to the form object correctly. So from the above we see that the form template actually create the property path that is used both for getting and setting the property in the form model that the widget is connected to. Yes, clear so far. Spring MVC does it very similar btw. From this we are not that far away from connecting formatting variant to the property path. In a state full scenario we are keeping the form object in e.g. a session, so the form template generator could store the associations between property paths and formating variants in the form object as well. These associations are then available to use when parsing the input from the post. And we can make sure that the right variant of the converter is used. Doesn't that tie both CForms and CTemplate together? Imagine using only one of both - which would break the concept. In a stateless scenario, we could instead store the assoications in the form page. We could e.g. add it to the property path in the name attribute: "tasks.2.startDate#short". Then the post parser can use the variant info for choosing the right converter. That's an interesting approach. IMO it should always work this way, not like the above one for stateful form-processing. And actually we are back to the Spring way using the path, aren't we? There is only the minor difference of using the full path vs. the anchor. The anchor adds additional flexibility since it can be specified in contrary to the generated path. I only really don't know if that flexibility is good. I mean you talked about scattered locale handling. This solution now tends to scattered variant handling IMO. I also don't know how it conforms with Parr's requirements for a template language. Doesn't this variant selection go very much into the direction of assumption about the data type? I can live with this concept but actually I prefer the path stuff of Spring much more since this is completely transparent to the template. It also completely decouples the object-to-string conversion from the templating while with the "select a variant"-approach in the template the conversion can not be done without the template. The question is what we lose when refraining from the variant: Only the possibility to use one property of the object twice in a template and format it differently. Anything else is addressed in Spring. So you can register form-specific converters. That's also how I handle it when I register converters for a particular path. In contrary type-specific converters are registered globally. (Where "globally" is not quite correct since the converters are prototypes anyway. The registration is a topic on its own below.) The property path could be used to determine the variant instead of specifying it explicitly. It's obviously not that flexible - but can't be broken in that way. That's why I would opt for class, locale and path, so add locale to Spring's PropertyEditorRegistry methods. It would be like having id selectors but not class selectors in CSS. I think this comparison is misleading. IMO path and variant are really similar concepts. It's only the way where/how they were specified and so the converter is selected. As we need handling of ELs, we could use "property paths" that includes the format variant e.g. "foo.bar#short" or even just "#short". The later for applying the beanEditor when the "short" variant is asked for. Yes, a combination of both (very similar) concepts seems to be possible easily. Do you mean that you agree about that it is unclear how to handle locals with the bean wrapper stuff? Or are you starting to see some solution? Both actually. I try to rephrase the confusing paragraph ... There is indeed no way to select a converter based on the locale at the moment. What you can do though is to register a locale-specific converter based on the request information (remember the initBinder() in my last mail). But this approach is really awkward since you need to do this in every controller you write. That's why I wrote "So you might drop that complete section from mind :-)"
Re: Clarification on converter concept
Joerg Heinicke pisze:
What do you mean by registering? The idea for converters is that you
just create a bean (that implements necessary interface) and you are
done.
Where does the template know from which converter to apply? For the
example ${myobj.startDate#short} "short" must actually be defined and
registered somewhere, doesn't it? How did you say: "short date (whatever
it means)" :-) That's defined by a particular converter which can be
looked up by the template in the registry.
It will be bean's ID pointing that this particular bean implements "short" variant. We use powerful Spring configurator[1] stuff for doing
the trick, see this[2] for an example:
The expressionCompilers property is a Map.
Yes, there is still a registry but neither EL user nor EL implementation must
care about it.
What was counter-intuitive apart from switching between both that I do
not like either?
The ${} and #{}, the impedance mismatch between objects and xml model:
JXPath on beans does not behave like on xml.
The ${} and #{} will be simplified. Could you elaborate on the "impedance mismatch"? I would like to see concrete examples to know what you
mean. I'm curious because I used to really like JXPath.
Ok, recently somebody posted the SimpleFormController Lifecycle Cheat
Sheet[2] in the Spring forum, which shows the request processing in the
controller. Don't try to understand it, I just want to show where we
are. One of the first things in the request processing is initBinder
which actually takes the request as parameter. That means you can
determine the locale in that method. You are supposed to register your
PropertyEditors in this method:
Binder.registerCustomEditor(Class, ProperyEditor);
So for the date converter:
Locale locale = // determine from request
DateFormat dateFormat = DateFormat.getDateInstance(SHORT, locale)
binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat,
..));
So it's not the PropertyEditor being locale-aware but the PropertyEditor
instantiation. It creates the proper (= correct locale) PropertyEditor.
But yes, I don't like it that much anyway. Actually I used it very
rarely in my project. There is a much better way to do this than those
scattering the PropertyEditors all over the place. So you might drop
that complete section from mind :-)
LOL ;-)
At least I understand you, now :-)
Architecture
The "converter architecture" as I imagine it consist of three parts.
* Converters:
* Converter registry:
* Integration:
I agree completely. It's only about the details. The only difference I
see actually is on which parameters the converter is chosen.
Count me in, I agree too.
Converters
--
IMO it would be cleaner to have the locale dependency in the registry
instead of in the converter.
I agree. This means locale is removed from the converter methods.
+1
"Date formats are not synchronized. It is recommended to create separate
format instances for each thread. If multiple threads access a format
concurrently, it must be synchronized externally."
Same for NumberFormat and probably others as well. So no advantage over
PropertyEditors which suffer from the same problem. I don't think we
need a "real" format cache, it only seems to complicate stuff. The
proposed ThreadLocal might be a solution. Spring holds them on the
binder where they get registered once. Might be limiting since it's
targetted to form processing obviously.
Yes, we don't want converter narrowed to Forms processing only.
Converter Registry
--
For a Cocoon framework I would prefer looking up a converter based on
class, locale and variant, while I don't see any obvious use cases for
property path.
Indeed the PropertyEditorRegistry seems not to meet our requirements.
(copied from further above, better fits in here)
The framework select based on data type and locale. But for e.g. dates
there are several different string representations (short, medium, full
and long or maybe some custom format) that the template or form author
needs to choose between. To me it seem reasonable to have a syntax for
making this possible in e.g. the template.
As I wrote repeatedly the possibility to influence the formatting from
the template breaks the two-way process. You can't parse a date
expecting a FULL pattern string when receiving a string formatted with
SHORT pattern. And there is no chance to get informed about this mismatch.
The property path could be used to determine the variant instead of
specifying it explicitly. It's obviously not that flexible - but can't
be broken in that way. That's why I would opt for class, locale and
path, so add locale to Spring's PropertyEditorRegistry methods.
Now I get your point, and understand your arguments. However, as we seen already Daniel proposed very neat solution. To elaborate a little I
guess there are two cases when data is returned to the server:
1
Re: Clarification on converter concept
Daniel Fagerstrom pisze:
That would be the case if expressions with converter variant modifiers
only was used alone as attribute values. But remember that expressions
in CTemplate can be embeded in text as well, e.g.:
The start date is ${myobj.startDate#short}.
In such cases having the modifier outside the expression would be harder
to parse. We chose '#' as a separator as it didn't seem to have any
significant meaning in the expression languages we had in mind when the
converters where discussed. We can always introduce some escaping
mechanism "##" e.g. for cases when a literal '#' is needed as part of an
expression.
Standard \# is more intuitive but generally I agree with your point.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Daniel Fagerstrom pisze: Just to clarify: I would much have preferred if we only had one expression language (EL) in Cocoon and a property style syntax like the Spring one or JEXL would be fine with me. But as ELs are used everywhere in Cocoon webapps, most users have a heavy investment in the current set of ELs. So we just cannot deprecate them and require all the users to rewrite all their webapps to the new "better" EL at one go. We need a mechanism that simplify for new users and new webapps by making it easy to use one default EL everywhere at the same time that we don't require users to rewrite their old webapps. This is the main motivation for the plugable EL architecture. What about map: language we have discussed earlier? I think it makes sense to have such a domain-specific, damn simple language. If it takes ten minutes to learn such a language and it improves readability, I think it makes to have one. Having bunch of general ELs is what I want to avoid too. First, from a separation of concern POV, it is IMO much preferable to influence the formating variant, both for output and input, in the form template. Second, we have the question if it is possible to accomplish ;) Yes, I think it is. Consider a form template, where you have various widgets: The form infrastructure creates two property paths from the id. One for accessing the start date from the form object to insert in the generated html page. And one property path is used as content of the name attribute in the generated html form element. The name attribute is then used by the browser when posting the filled in value of the form element. In the case of nested widgets, the property path is created from all the ids of the parent widget as well, so we can have property paths like tasks.2.startDate, if the start date is part of a task list, e.g. So from the above we see that the form template actually create the property path that is used both for getting and setting the property in the form model that the widget is connected to. From this we are not that far away from connecting formatting variant to the property path. In a state full scenario we are keeping the form object in e.g. a session, so the form template generator could store the associations between property paths and formating variants in the form object as well. These associations are then available to use when parsing the input from the post. And we can make sure that the right variant of the converter is used. In a stateless scenario, we could instead store the assoications in the form page. We could e.g. add it to the property path in the name attribute: "tasks.2.startDate#short". Then the post parser can use the variant info for choosing the right converter. That's a really neat idea! I have not thought about it that way and I really like it! :-) So as you can see it is possible to put the choice of formatting variant in the form template so that the two-way aspect is respected. Getting back to the earth, are you sure that all browsers will be happy with # character in field's name? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Joerg Heinicke skrev:
On 05.07.2007 00:47, Grzegorz Kossakowski wrote:
...
I always found the JEXL/JXPath syntax rather counterintuitive.
What was counter-intuitive apart from switching between both that I do
not like either?
The ${} and #{}, the impedance mismatch between objects and xml model:
JXPath on beans does not behave like on xml.
How Spring syntax looks like and how it is better than JXPath/JEXL?
Bean property syntax which as used in other template languages like
Velocity and scripting languages as well: object1.object2.property.
Just to clarify: I would much have preferred if we only had one
expression language (EL) in Cocoon and a property style syntax like the
Spring one or JEXL would be fine with me.
But as ELs are used everywhere in Cocoon webapps, most users have a
heavy investment in the current set of ELs. So we just cannot deprecate
them and require all the users to rewrite all their webapps to the new
"better" EL at one go. We need a mechanism that simplify for new users
and new webapps by making it easy to use one default EL everywhere at
the same time that we don't require users to rewrite their old webapps.
This is the main motivation for the plugable EL architecture.
...
On 05.07.2007 14:24, Daniel Fagerstrom wrote:
...
Converter Registry
--
For a Cocoon framework I would prefer looking up a converter based on
class, locale and variant, while I don't see any obvious use cases for
property path.
Indeed the PropertyEditorRegistry seems not to meet our requirements.
(copied from further above, better fits in here)
The framework select based on data type and locale. But for e.g. dates
there are several different string representations (short, medium, full
and long or maybe some custom format) that the template or form author
needs to choose between. To me it seem reasonable to have a syntax for
making this possible in e.g. the template.
As I wrote repeatedly the possibility to influence the formatting from
the template breaks the two-way process. You can't parse a date
expecting a FULL pattern string when receiving a string formatted with
SHORT pattern. And there is no chance to get informed about this mismatch.
First, from a separation of concern POV, it is IMO much preferable to
influence the formating variant, both for output and input, in the form
template.
Second, we have the question if it is possible to accomplish ;) Yes, I
think it is. Consider a form template, where you have various widgets:
The form infrastructure creates two property paths from the id. One for
accessing the start date from the form object to insert in the generated
html page. And one property path is used as content of the name
attribute in the generated html form element. The name attribute is then
used by the browser when posting the filled in value of the form
element. In the case of nested widgets, the property path is created
from all the ids of the parent widget as well, so we can have property
paths like tasks.2.startDate, if the start date is part of a task list, e.g.
So from the above we see that the form template actually create the
property path that is used both for getting and setting the property in
the form model that the widget is connected to. From this we are not
that far away from connecting formatting variant to the property path.
In a state full scenario we are keeping the form object in e.g. a
session, so the form template generator could store the associations
between property paths and formating variants in the form object as
well. These associations are then available to use when parsing the
input from the post. And we can make sure that the right variant of the
converter is used.
In a stateless scenario, we could instead store the assoications in the
form page. We could e.g. add it to the property path in the name
attribute: "tasks.2.startDate#short". Then the post parser can use the
variant info for choosing the right converter.
So as you can see it is possible to put the choice of formatting variant
in the form template so that the two-way aspect is respected.
The property path could be used to determine the variant instead of
specifying it explicitly. It's obviously not that flexible - but can't
be broken in that way. That's why I would opt for class, locale and
path, so add locale to Spring's PropertyEditorRegistry methods.
It would be like having id selectors but not class selectors in CSS. But
as we saw choosing format variant in format templates is possible.
As we need handling of ELs, we could use "property paths" that includes
the format variant e.g. "foo.bar#short" or even just "#short". The later
for applying the beanEditor when the "short" variant is asked for.
So as a conclusion: it would be nice to reuse the Spring stuff and
there are big overlaps, but especially for locale handling it is not
obvious to me how to use it. Then of course there is the question if
i
Re: Clarification on converter concept
On 05.07.2007 00:47, Grzegorz Kossakowski wrote:
As Daniel pointed out, it has been discussed but I must admit I'm not
completely sure that I "feel" the concept.
I like Daniel's post [1] a lot. It goes very much into the direction of
PropertyEditors. Quoting him:
"As a solution to the problem he sugests MVCR
(Model-View-Controller-Renderer), where the renderer is responsible for
converting (Java) data types to displayable strings. The renderer can be
responsible for localization of numbers etc as well. The renderer is an
extra step between model and view."
The renderer applies very much to the original idea of PropertyEditor.
"Displayable" in the GUI programming might be a bit more complex. That's
why there is a method getCustomEditor() returning a java.awt.Component
for example. For web programming to and from string conversion should be
sufficient.
"The simplest possible renderer is to just implement toString() in the
classes one is going to access in the view. But a better SoC is to have
a separate rendering component. In this case the object from the model
is first accessed by an expression in a suitable expression language and
then the object is rendered to a displayable string by the rendering
component and at last the displayable string is emited by the template
engine."
The externalized toString() describes quite perfectly what
PropertyEditor actually does.
How does it work (pseudo code and simplified):
BeanWrapper wrappedOM = new BeanWrapper(objectModel);
String displayString = wrappedOM.getProperty(aPath);
Internally BeanWrapper does:
Object value = getPropertyValue(objectModel, aPath);
Class valueType = getPropertyType(objectModel, aPath);
PropertyEditor editor =
PropertyEditorRegistry.findCustomEditor(valueType, aPath);
editor.setValue(value);
return editor.getAsText();
From purist's point of view it is really _bad_ idea to use interfaces
and classes for something that they were not invented for.
See above, it's not that far away. Unfortunately, Java started with GUI
programming before it founds its niche, the web programming. That's what
you still can find on this interface.
To be honest I'm not Spring specialist so I do not understand which
infrastructure exactly and how it helps. Even more confusing is that
something is going to be replaced by something else. I really don't know
what replaces what and what's for. Sorry.
I feared that my first collection of thoughts was too confusing. Will
focus on the important stuff now.
Do you want to state that you can define only one Converter for Foo
class? Or do you want to say that in Spring MVC you can register
converter for Foo class that is available by using particular epxression
(like xyz/bar/foo)?
The latter. If xyz/bar/foo would not be of type Foo it would not match.
What do you mean by registering? The idea for converters is that you
just create a bean (that implements necessary interface) and you are done.
Where does the template know from which converter to apply? For the
example ${myobj.startDate#short} "short" must actually be defined and
registered somewhere, doesn't it? How did you say: "short date (whatever
it means)" :-) That's defined by a particular converter which can be
looked up by the template in the registry.
I always found the JEXL/JXPath syntax rather counterintuitive.
What was counter-intuitive apart from switching between both that I do
not like either?
The ${} and #{}, the impedance mismatch between objects and xml model:
JXPath on beans does not behave like on xml.
How Spring syntax looks like and how it is better than JXPath/JEXL?
Bean property syntax which as used in other template languages like
Velocity and scripting languages as well: object1.object2.property.
3. Locale. PropertyEditors have no support for i18n/l10n. [..]
I had a look at Spring's CustomDateEditor [9]. It's set up with a
DateFormat. Since PropertyEditors should be prototypes anyway I
don't see a problem to inject the Locale into the editor on
registration as done via DateFormat for the CustomDateEditor.
That works without the PropertyEditors being locale-aware.
It all looks like plumbing and is counter-intuitive for my taste. It may
be that I miss the idea totally. If you could explain it and say way
such solution is better than proposed one it would be very helpful.
Ok, recently somebody posted the SimpleFormController Lifecycle Cheat
Sheet[2] in the Spring forum, which shows the request processing in the
controller. Don't try to understand it, I just want to show where we
are. One of the first things in the request processing is initBinder
which actually takes the request as parameter. That means you can
determine the locale in that method. You are supposed to register your
PropertyEditors in this method:
Binder.registerCustomEditor(Class, ProperyEditor);
So for the date converter:
Locale locale = // determine from request
DateFormat dateFormat = DateFormat.getDateI
Re: Clarification on converter concept
On 05.07.2007 18:26, Grzegorz Kossakowski wrote:
I had a feeling that there is much more besides Date/Number/Currency
formatting but now I think that I was suffering from over-generalization
problem. The converter concept is that simple how you describe it but
it's not wrong because it solves very concrete problem.
Hopefully it goes beyond simple date, number or currency formatting!
With Spring's usage of PropertyEditors you can bind objects directly to
a selection list. You don't care how it gets converted to string and
back, the PropertyEditor does it. The CForms way is more complicated
[1], you have to convert your collection to a
org.apache.cocoon.forms.datatype.SelectionList.
In my Spring MVC project I have written one (!) EntityPropertyEditor
which is used for all domain entities in my application. Now in JSP
using Spring's form taglib I just write:
Which company do you want to work for?
itemLabel="name"/>
"user" is the object the form is bound to.
"selectedCompany" is a property of the use and of type entity or
company, not a entity id or something like that.
"companies" is a collection of entities/companies, e.g. retrieved from
RequestContext.
"name" is a property of the entity/company, here used as label.
That's all. No selection list generation. No caring about the key. The
in the is correctly preselected if there was one set
on the user. I get a company instance set on user.selectedCompany property.
locale="${cocoon.request.locale}">
for each date. That is of course quite OK to write, but it clearly
clutters the code, and it is not that obvious for a non developer.
With converters it would be more like:
${myobj.startDate#short}
Isn't that only a shorter syntax?
The focus on template formatting is rather limiting. IMO it MUST be a
two-way process or you can't write back to the object model. Selecting
the converter in the template makes it just impossible.
We might have a different focus in mind. But if we talk about a general
converter concept we should not start with such a limitation.
Joerg
[1] http://cocoon.apache.org/2.1/userdocs/widgetconcepts/selectionlists.html
Re: Clarification on converter concept
Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
...
I had a feeling that there is much more besides Date/Number/Currency
formatting but now I think that I was suffering from over-generalization
problem. The converter concept is that simple how you describe it but
it's not wrong because it solves very concrete problem.
Nothing spectacular this time ;) But improving usability is consists
mainly of lots of small improvements.
Now I think that I fully get the idea and we can focus on discussing how
to implement it.
Anyway, say that you have a couple of dates in your model bean that
you would like to render on a web page using CTemplate. Then you
currently would need to write something like (haven't checked the
details):
locale="${cocoon.request.locale}">
for each date. That is of course quite OK to write, but it clearly
clutters the code, and it is not that obvious for a non developer.
With converters it would be more like:
${myobj.startDate#short}
and
${myobj.startDate}
Personally, I prefer ${myboject.startDate}#short syntax because choosing
converter should not be part of expression (it would be hard to
distinguish where expression part ends and converter name begins in some
cases). The syntax would also imply that conversion is performed after
obtaining value (object) by evaluating the exception.
That would be the case if expressions with converter variant modifiers
only was used alone as attribute values. But remember that expressions
in CTemplate can be embeded in text as well, e.g.:
The start date is ${myobj.startDate#short}.
In such cases having the modifier outside the expression would be harder
to parse. We chose '#' as a separator as it didn't seem to have any
significant meaning in the expression languages we had in mind when the
converters where discussed. We can always introduce some escaping
mechanism "##" e.g. for cases when a literal '#' is needed as part of an
expression.
/Daniel
Re: Clarification on converter concept
Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
...
Yes, but I really didn't get the idea fully. Now I think that it may
be just a lack of use cases for converter. Would you be so kind to
provide some examples how it could work in particular cases and how it
would be helpful for Cocoon developer?
Sometimes abstract explanations hide the basic idea, actually.
Didn't my examples from CForms and CTemplate below help you?
I had a feeling that there is much more besides Date/Number/Currency formatting but now I think that I was suffering from
over-generalization problem. The converter concept is that simple how you describe it but it's not wrong because it solves very concrete
problem.
Now I think that I fully get the idea and we can focus on discussing how to
implement it.
Anyway, say that you have a couple of dates in your model bean that you
would like to render on a web page using CTemplate. Then you currently
would need to write something like (haven't checked the details):
locale="${cocoon.request.locale}">
for each date. That is of course quite OK to write, but it clearly
clutters the code, and it is not that obvious for a non developer. With
converters it would be more like:
${myobj.startDate#short}
and
${myobj.startDate}
Personally, I prefer ${myboject.startDate}#short syntax because choosing converter should not be part of expression (it would be hard to
distinguish where expression part ends and converter name begins in some cases). The syntax would also imply that conversion is performed
after obtaining value (object) by evaluating the exception.
Maybe, but in that case you have one way of handling formating for forms
and another way for templates. And you would need two configurations
instead of one. Also from a conceptual standpoint it is better to
separate the rendering part (template) and the model part (form
definition). See my abstract text ;)
http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 for more
about the model-rendering separation.
Yes, I understand it now.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
...
Yes, but I really didn't get the idea fully. Now I think that it may
be just a lack of use cases for converter. Would you be so kind to
provide some examples how it could work in particular cases and how it
would be helpful for Cocoon developer?
Sometimes abstract explanations hide the basic idea, actually.
Didn't my examples from CForms and CTemplate below help you?
Anyway, say that you have a couple of dates in your model bean that you
would like to render on a web page using CTemplate. Then you currently
would need to write something like (haven't checked the details):
for each date. That is of course quite OK to write, but it clearly
clutters the code, and it is not that obvious for a non developer. With
converters it would be more like:
${myobj.startDate#short}
and
${myobj.startDate}
for the default formatting.
And for CForms you would use exactly the same notation.
Of course there already is possible to do localization in CForms and
CTemplate but it is not that convenient. In CForms you need a
declaration like
MM/dd/
dd/MM/
dd-MM-
see
http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html#formatting+%28date%29,
for each date field in your form definition (maybe there are some
more convenient way to do it with form libraries?).
AFAIR, using form libraries is the solution you look for in this case.
Maybe, but in that case you have one way of handling formating for forms
and another way for templates. And you would need two configurations
instead of one. Also from a conceptual standpoint it is better to
separate the rendering part (template) and the model part (form
definition). See my abstract text ;)
http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 for more
about the model-rendering separation.
In CTemplate you instead use special tags
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#formatDate.
With these constructions a localized Cocoon webapp becomes cluttered
with localization code.
Are there any use-cases apart form Date/Number/Currency conversion?
I think those are the main use cases. But I think it should be plugable
so that people are able to write converters for there own classes. As
you can see in
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/convertor/,
cforms contains a number of different convertors.
...
It is perfectly valid to have more than one converter for particular
type, each one identified by unique, short identifier. Thanks to
converter concept following syntax:
{jxpath:cocoon/request/parameters/date}#shortDate
will be used to tell Cocoon that user expects 'date' request
parameter to be formatted as short date (whatever it means).
Short etc. is from DateFormat
http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html.
So converter is just a wrapper for configured DateFormat, right?
A date converter would be that, yes.
/Daniel
Re: Clarification on converter concept
Joerg Heinicke skrev:
On 03.07.2007 21:47, Grzegorz Kossakowski wrote:
...
The converter is locale-aware so string produced by converter may
depend on user's locale (e.g. Date representation).
Don't know. Read on ...
Locale awareness is part of the idea.
...
Thanks to converter concept following syntax:
{jxpath:cocoon/request/parameters/date}#shortDate
Does that one (and converters in any way) already exist?
In Cocoon we only have the "convertors" in CForms. The "converter
concept" is about improving the CForms convertors and making them
available in templates (and possibly in other places).
There is an old prototype https://issues.apache.org/jira/browse/COCOON-1345.
will be used to tell Cocoon that user expects 'date' request
parameter to be formatted as short date (whatever it means).
I ask because I don't consider that one a good idea. Not the syntax
itself, but the fact that you can "select" a particular converter.
Why? Read on ... :-)
Normally you don't choose what converter to use. The framework select
based on data type and locale. But for e.g. dates there are several
different string representations (short, medium, full and long or maybe
some custom format) that the template or form author needs to choose
between. To me it seem reasonable to have a syntax for making this
possible in e.g. the template.
...
Think so. But ... now the stuff I want to add.
I don't know if that topic has already been discussed. At least I
can't remember - but that might also be one of the unread old threads
in my inbox. If you start from scratch I want to suggest to have a
look at how Spring handles this before we invent anything new.
...
That was quite much, I hope you could follow. I'm really deep inside
Spring MVC at the moment :-) Feel free to ask where I should elaborate.
I didn't manage to follow all the technical details. But in general it
would of course be good to reuse the Spring stuff. The main hurdles is
that the Spring mechanism doesn't support locales in any systematic way
and that it is not obvious how to use it for a webapp that supports
multiple locales. While it clearly has a lot of overlap with what we
want for the new improved OM, expression handling and converters it is
far from an 1-1 mapping.
It would be nice if you could expand a little bit more on what
advantages in using the Spring stuff that you see.
Architecture
Anyway, let us discuss architecture a little bit so that we can be more
concrete about how the Spring stuff would fit in:
The "converter architecture" as I imagine it consist of three parts.
* Converters: that provides a bidirectional mapping between objects and
string representations of them.
* Converter registry: where converters are registered together with what
type they act on and optionally what locale they handle and maybe a
variant (the later for handling multiple representations). The registry
has a lookup method that finds the right converter based on data type,
locale and variant. The lookup method probably contains default
strategies and fall back methods for parameter combinations where no
converter is registered.
* Integration: The template and forms uses the converter registry for
finding the right converter for going from objects found with the
expression language to string representation and for converting form
input to the right kind of object.
Applying the architecture
=
Converters
--
For the converters we have the CForms convertors today
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/convertor/Convertor.java,
the most imortant methods are
ConversionResult convertFromString(String value, Locale locale,
FormatCache formatCache);
String convertToString(Object value, Locale locale, FormatCache
formatCache);
It is not that different from the setAsText and getAsText methods of the
PropertyEditor
http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditor.html.
An important differences are that the convertor depends on a locale
which the property editor doesn't. IMO it would be cleaner to have the
locale dependency in the registry instead of in the converter. Next the
convertor needs a format cache, this is IIRC because date and number
formating objects not are thread safe and takes some work to construct.
When the forms framework was written, thread locals where quite
inefficient, so an external cache was used instead. This is not a
problem in Java 1.4 so we could use a thread local cache and get rid of
the format cache in the API. Last the convertFromString returns a
ConversionResult while setAsText throws a IllegalArgumentException for
badly formated input strings. I haven't looked at the details and have
no opinion about this.
As a conclusion I think that PropertyEditors would work fine for us if
we find it worthwhile. Some effort is needed for integrat
Re: Clarification on converter concept
Daniel Fagerstrom pisze: Something like that. You find some background in http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 and http://article.gmane.org/gmane.text.xml.cocoon.devel/43141. Also I think we already discussed converters while discussing your GSoC application. A small side note: Providing links to crucial posts instead of whole threads really helps the reader. I must adapt this behaviour. :-) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
Convertor was from CForms, converter might be a better name.
There are three (including me) people that agree on this, I would said that it
is already decided. ;-)
Something like that. You find some background in
http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 and
http://article.gmane.org/gmane.text.xml.cocoon.devel/43141. Also I think
we already discussed converters while discussing your GSoC application.
Yes, but I really didn't get the idea fully. Now I think that it may be just a lack of use cases for converter. Would you be so kind to
provide some examples how it could work in particular cases and how it would be helpful for Cocoon developer?
Sometimes abstract explanations hide the basic idea, actually.
The main usage is localization of string representations of dates and
numbers. This is needed both for CTemplate and CForms. For CForms the
converter needs to be bidirectional as well.
Yes.
Of course there already is possible to do localization in CForms and
CTemplate but it is not that convenient. In CForms you need a
declaration like
MM/dd/
dd/MM/
dd-MM-
see
http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html#formatting+%28date%29,
for each date field in your form definition (maybe there are some more
convenient way to do it with form libraries?).
AFAIR, using form libraries is the solution you look for in this case.
In CTemplate you instead use special tags
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#formatDate.
With these constructions a localized Cocoon webapp becomes cluttered
with localization code.
Are there any use-cases apart form Date/Number/Currency conversion?
There are certainly room for some improvements:
First, it would be better to have *one* localization method that could
be used in both CForms and CTemplate (and possibly at other places), so
it is enough to learn one method for newcomer.
+1
Second, it should be enough to declare the localized rules for getting
from an object to its localized string representation in one place
(configuration file), needing to do it for each use makes the code hard
to maintain and read.
+1
Third, there should be a default converter (possibly localized) for
important data types, so you don't need to write anything at all in your
forms or templates in most cases.
...and option to override default converter.
It is perfectly valid to have more than one converter for particular
type, each one identified by unique, short identifier. Thanks to
converter concept following syntax:
{jxpath:cocoon/request/parameters/date}#shortDate
will be used to tell Cocoon that user expects 'date' request parameter
to be formatted as short date (whatever it means).
Short etc. is from DateFormat
http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html.
So converter is just a wrapper for configured DateFormat, right?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Joerg Heinicke pisze:
First of all, thanks for your insightful comment!
I'll address all the points separately.
In CForms it's convertor but IIRC it was considered a strange name
though correct. Google: 10 million hits vs. 100 millions. So converter
is probably the more natural choice.
Same here.
It is perfectly valid to have more than one converter for particular
type, each one identified by unique, short identifier.
Yes.
There is nothing to comment here, but I mark this as (*) to reference it
further.
Thanks to converter concept following syntax:
{jxpath:cocoon/request/parameters/date}#shortDate
Does that one (and converters in any way) already exist?
Yes and no. We don't have converters applied to values returned by ELs but its my task to introduce them if we agree we need them. The main
idea is that we have them already in CForms so it's quite natural to extend the concept to the areas when conversion is also needed.
will be used to tell Cocoon that user expects 'date' request parameter
to be formatted as short date (whatever it means).
I ask because I don't consider that one a good idea. Not the syntax
itself, but the fact that you can "select" a particular converter. Why?
Read on ... :-)
Fighting with myself to not answer right away, right here ;-)
Think so. But ... now the stuff I want to add.
I don't know if that topic has already been discussed. At least I can't
remember - but that might also be one of the unread old threads in my
inbox. If you start from scratch I want to suggest to have a look at how
Spring handles this before we invent anything new.
As Daniel pointed out, it has been discussed but I must admit I'm not completely sure that I "feel" the concept. That uncertainty made shape
of my original mail. Nevertheless I'm all eager to learn from others.
Actually it's not even invented by Spring but they use so called
PropertyEditors [1]. They are part of the JDK (even before Java 5 ;-))
and in the package java.beans. Since this stuff was once targetted for
tool providers for introspection this interface is anything else than
slim, but after my experiences with Spring and many built-in and custom
PropertyEditors that is not a problem at all. The reason is the
PropertyEditorSupport [2] providing a meaningful default implementation.
So when you need to write your own PropertyEditor you actually extend
PropertyEditorSupport and implement only getAsText() (conversion from
object to string) and setAsText(String) (other way around).
From purist's point of view it is really _bad_ idea to use interfaces and classes for something that they were not invented for. I'm not
purist and the world is dynamic so I can live with "hacky" solutions like that one. My comment reflects my first impression after reading
about it.
One downside: PropertyEditors are not thread-safe. Spring used to
synchronize on them in 1.x, a real bottle-neck. In 2.x you are
encouraged to work with prototypes, Spring provides the necessary
infrastructure [3].
To be honest I'm not Spring specialist so I do not understand which infrastructure exactly and how it helps. Even more confusing is that
something is going to be replaced by something else. I really don't know what replaces what and what's for. Sorry.
Now to some particular questions.
1. Selecting a converter. That's really a bad choice. That's like
in JSP/JSTL. Why is it bad? Imagine setting the
formatted date as value of an input field. Now the form is submitted.
Who is supposed to parse that date string? It must be a two-way process
- like it is done in CForms with convertors or PropertyEditors in Spring
MVC. They are registered for a particular widget (CForms), type/class or
path or combination of the both (Spring MVC) [6].
We can provide the possibility for read-only stuff which ends in text
but I wonder what for. In Spring MVC I also use the PropertyEditors for
those use cases. I register them once anyway.
Do you want to state that you can define only one Converter for Foo class? Or do you want to say that in Spring MVC you can register
converter for Foo class that is available by using particular epxression (like xyz/bar/foo)?
What do you mean by registering? The idea for converters is that you just
create a bean (that implements necessary interface) and you are done.
2. When not selecting a converter you also don't need a syntax for it
:-) What about the syntax for the paths itself? I always found the
JEXL/JXPath syntax rather counterintuitive. Maybe that had improved with
the JXTemplate refactoring, especially the need to switch between both.
What was counter-intuitive apart from switching between both that I do not like
either?
IIRC a goal of the refactoring was also to allow easy addition of
further expression languages. So what about adding the path syntax which
is really intuitive. Spring provides the whole infrastructure with
BeanWrapperImpl [3, 7] as the central access poin
Re: Clarification on converter concept
Grzegorz Kossakowski skrev:
Hello,
I'm glad to see that we agreed on design of OM, now I would like to
focus on converter concept.
First of all, I would like to know which form should be preferred:
"converter" or "convertor". Since both are valid (according to
dictionary.com) I'm not really sure which one I should pick.
Convertor was from CForms, converter might be a better name.
Now I must admit that I'm not sure if I understand converter concept.
Let me explain my current understanding.
Basically, converter for certain type is a class that performs
conversion between that type and its string representation. The
converter is locale-aware so string produced by converter may depend
on user's locale (e.g. Date representation).
Something like that. You find some background in
http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 and
http://article.gmane.org/gmane.text.xml.cocoon.devel/43141. Also I think
we already discussed converters while discussing your GSoC application.
The main usage is localization of string representations of dates and
numbers. This is needed both for CTemplate and CForms. For CForms the
converter needs to be bidirectional as well.
Of course there already is possible to do localization in CForms and
CTemplate but it is not that convenient. In CForms you need a
declaration like
MM/dd/
dd/MM/
dd-MM-
see
http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html#formatting+%28date%29,
for each date field in your form definition (maybe there are some more
convenient way to do it with form libraries?).
In CTemplate you instead use special tags
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#formatDate.
With these constructions a localized Cocoon webapp becomes cluttered
with localization code. There are certainly room for some improvements:
First, it would be better to have *one* localization method that could
be used in both CForms and CTemplate (and possibly at other places), so
it is enough to learn one method for newcomer.
Second, it should be enough to declare the localized rules for getting
from an object to its localized string representation in one place
(configuration file), needing to do it for each use makes the code hard
to maintain and read.
Third, there should be a default converter (possibly localized) for
important data types, so you don't need to write anything at all in your
forms or templates in most cases.
It is perfectly valid to have more than one converter for particular
type, each one identified by unique, short identifier. Thanks to
converter concept following syntax:
{jxpath:cocoon/request/parameters/date}#shortDate
will be used to tell Cocoon that user expects 'date' request parameter
to be formatted as short date (whatever it means).
Short etc. is from DateFormat
http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html.
For each type it is possible to define default converter and it is
assumed that Cocoon ships with set of default converters for
primitive, common types.
Yes.
/Daniel
Re: Clarification on converter concept
On 03.07.2007 21:47, Grzegorz Kossakowski wrote:
I'm glad to see that we agreed on design of OM, now I would like to
focus on converter concept.
First of all, I would like to know which form should be preferred:
"converter" or "convertor". Since both are valid (according to
dictionary.com) I'm not really sure which one I should pick.
In CForms it's convertor but IIRC it was considered a strange name
though correct. Google: 10 million hits vs. 100 millions. So converter
is probably the more natural choice.
Now I must admit that I'm not sure if I understand converter concept.
Let me explain my current understanding.
Basically, converter for certain type is a class that performs
conversion between that type and its string representation.
Yes.
The
converter is locale-aware so string produced by converter may depend on
user's locale (e.g. Date representation).
Don't know. Read on ...
It is perfectly valid to have more than one converter for particular
type, each one identified by unique, short identifier.
Yes.
Thanks to converter concept following syntax:
{jxpath:cocoon/request/parameters/date}#shortDate
Does that one (and converters in any way) already exist?
will be used to tell Cocoon that user expects 'date' request parameter
to be formatted as short date (whatever it means).
I ask because I don't consider that one a good idea. Not the syntax
itself, but the fact that you can "select" a particular converter. Why?
Read on ... :-)
For each type it is possible to define default converter and it is
assumed that Cocoon ships with set of default converters for primitive,
common types.
Ok.
Is the description above exhaust the converter concept?
Think so. But ... now the stuff I want to add.
I don't know if that topic has already been discussed. At least I can't
remember - but that might also be one of the unread old threads in my
inbox. If you start from scratch I want to suggest to have a look at how
Spring handles this before we invent anything new.
Actually it's not even invented by Spring but they use so called
PropertyEditors [1]. They are part of the JDK (even before Java 5 ;-))
and in the package java.beans. Since this stuff was once targetted for
tool providers for introspection this interface is anything else than
slim, but after my experiences with Spring and many built-in and custom
PropertyEditors that is not a problem at all. The reason is the
PropertyEditorSupport [2] providing a meaningful default implementation.
So when you need to write your own PropertyEditor you actually extend
PropertyEditorSupport and implement only getAsText() (conversion from
object to string) and setAsText(String) (other way around).
One downside: PropertyEditors are not thread-safe. Spring used to
synchronize on them in 1.x, a real bottle-neck. In 2.x you are
encouraged to work with prototypes, Spring provides the necessary
infrastructure [3].
Now to some particular questions.
1. Selecting a converter. That's really a bad choice. That's like
in JSP/JSTL. Why is it bad? Imagine setting the
formatted date as value of an input field. Now the form is submitted.
Who is supposed to parse that date string? It must be a two-way process
- like it is done in CForms with convertors or PropertyEditors in Spring
MVC. They are registered for a particular widget (CForms), type/class or
path or combination of the both (Spring MVC) [6].
We can provide the possibility for read-only stuff which ends in text
but I wonder what for. In Spring MVC I also use the PropertyEditors for
those use cases. I register them once anyway.
2. When not selecting a converter you also don't need a syntax for it
:-) What about the syntax for the paths itself? I always found the
JEXL/JXPath syntax rather counterintuitive. Maybe that had improved with
the JXTemplate refactoring, especially the need to switch between both.
IIRC a goal of the refactoring was also to allow easy addition of
further expression languages. So what about adding the path syntax which
is really intuitive. Spring provides the whole infrastructure with
BeanWrapperImpl [3, 7] as the central access point. Spring e.g.
integrates it with JSP via a tag [8], we would need to add integration
with our template stuff.
3. Locale. PropertyEditors have no support for i18n/l10n. (Actually I
wonder why. Shouldn't tool providers also show localized string
representations of a bean?) So how to do it? I had a look at Spring's
CustomDateEditor [9]. It's set up with a DateFormat. Since
PropertyEditors should be prototypes anyway I don't see a problem to
inject the Locale into the editor on registration as done via DateFormat
for the CustomDateEditor. That works without the PropertyEditors being
locale-aware.
That was quite much, I hope you could follow. I'm really deep inside
Spring MVC at the moment :-) Feel free to ask where I should elaborate.
Regards,
Joerg
[1] http://java.sun.com/j2se/1.4.2/docs/api/java/b
Clarification on converter concept
Hello,
I'm glad to see that we agreed on design of OM, now I would like to focus on
converter concept.
First of all, I would like to know which form should be preferred: "converter" or
"convertor". Since both are valid (according to
dictionary.com) I'm not really sure which one I should pick.
Now I must admit that I'm not sure if I understand converter concept. Let me
explain my current understanding.
Basically, converter for certain type is a class that performs conversion between that type and its string representation. The converter is
locale-aware so string produced by converter may depend on user's locale (e.g. Date representation). It is perfectly valid to have more than
one converter for particular type, each one identified by unique, short identifier. Thanks to converter concept following syntax:
{jxpath:cocoon/request/parameters/date}#shortDate
will be used to tell Cocoon that user expects 'date' request parameter to be
formatted as short date (whatever it means).
For each type it is possible to define default converter and it is assumed that Cocoon ships with set of default converters for primitive,
common types.
Is the description above exhaust the converter concept?
Thanks for your opinions.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
