New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement to Rich Text Editor #669

Closed
brucetrask opened this Issue Mar 6, 2015 · 6 comments

Comments

Projects
None yet
4 participants
@brucetrask

brucetrask commented Mar 6, 2015

Thanks to Arjan for handling #614.
I have a new question now regarding the Rich Text Editor. FitLibrary provides quite some mechanisms for embedded tables, not just embedded hash tables but other more complicated tables. A great example of this is the DomainObjectFixture under the FitLibrary/FitNesseRoot (attached).
screen shot 2015-03-06 at 12 26 48 pm

The wiki syntax they use is variables and such to create these tables. The Rich Test Editor does not currently target this syntax or arbitrarily complex tables within tables. FitLibrary as well does not handle the fitnesse hash table wiki text. The wiki context for that example attached is

!-fitlibrary.specify.AggregateDomainObject-! |
!***< def

!define phones (|''phone''|
| 411 |
| 549 |
)

!define address1 (|''address1''|Auckland|
| ''address2'' | NZ |
)

!define address2 (|''address1''|Portland|
| ''address2'' | USA |
)

!define address3 (|''address1''|Portland|
| ''address2'' | USAa |
)

!define authors (|''name''|''phones''|''address''|
| Rick | ${phones} | ${address2} |
| Ward | | ${address3} |
)

!define authors2 (|''name''|''phones''|''address''|
| Rick | ${phones} | ${address3} |
| Ward | | ${address3} |
)

!define attributes (|''name''|''value''|
| ''title'' | Fit For Developing Software |
| ''date'' | 2005 |

)

!define publisher (|''name''|Prentice Hall|
)
*!
| ''create book'' |
| ''attributes'' | ${attributes} |
| ''authors'' | ${authors} |
| ''publisher'' | ${publisher} |

| ''check book'' |
| ''attributes'' | ${attributes} |
| ''authors'' | ${authors2} |
| ''publisher'' | ${publisher} |

| ''expected test results'' | 14 | ''right'' | 0 | ''wrong'' | 0 | ''ignored'' | 0 | ''exceptions'' |

I was hoping to get the committers thoughts on extending the Rich Text Editor to also target these types of tables that ultimately are processed by FitLibrary.

Thanks in advance.
Regards,
Bruce

@clobob

This comment has been minimized.

Show comment
Hide comment
@clobob

clobob Mar 13, 2015

hope this will be appear in the latest version.

clobob commented Mar 13, 2015

hope this will be appear in the latest version.

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Feb 3, 2016

Collaborator

This would make the rich text editor to complicated. The RTE should not have to deal with every feature possible in a wiki page, just make it easier for non-programmers to work with the wiki.

By nesting tables, things tend to become complicated pretty quickly.

Collaborator

amolenaar commented Feb 3, 2016

This would make the rich text editor to complicated. The RTE should not have to deal with every feature possible in a wiki page, just make it easier for non-programmers to work with the wiki.

By nesting tables, things tend to become complicated pretty quickly.

@amolenaar amolenaar closed this Feb 3, 2016

@ALuckyGuy

This comment has been minimized.

Show comment
Hide comment
@ALuckyGuy

ALuckyGuy Feb 4, 2016

I'll add my two cents here... the RTE's inability to handle nested tables means it practically does require a programmer to create them. Combined with the fact that it used to horribly mangle nested tables if you simply opened a page with RTE enabled, it's made RTE mode unusable. Not sure if the RTE will at least not lose data when dealing with nested tables now - been afraid to mess with it, and we advise our users not to as well.

I think it would be great if the RTE could handle nested tables. If it could, it would make nested tables much more approachable for non-technical staff. I think a table within a table is a pretty straight-forward concept when it's easy to visualize, and in fact our users don't have trouble understanding the data until they go into edit mode.

Also, I tend to make a distinction between nested tables and hashes, in that a hash can be thought of as a special case nested table... it just has 1 row. To create them within the RTE does mean another set of controls are necessary. However I believe the same controls that already exist for tables could be used for editing a nested table as long as it was possible to indicate you wished to create a new table within the active cell. At that point all table controls would be working with the interior table until positioned outside of it.

Anyway, I'm sure it's not trivial to implement, but I do see the lack of nested table support as a huge missing feature in the RTE, and a hurdle keeping many less technical people from otherwise working with nested table structures.

ALuckyGuy commented Feb 4, 2016

I'll add my two cents here... the RTE's inability to handle nested tables means it practically does require a programmer to create them. Combined with the fact that it used to horribly mangle nested tables if you simply opened a page with RTE enabled, it's made RTE mode unusable. Not sure if the RTE will at least not lose data when dealing with nested tables now - been afraid to mess with it, and we advise our users not to as well.

I think it would be great if the RTE could handle nested tables. If it could, it would make nested tables much more approachable for non-technical staff. I think a table within a table is a pretty straight-forward concept when it's easy to visualize, and in fact our users don't have trouble understanding the data until they go into edit mode.

Also, I tend to make a distinction between nested tables and hashes, in that a hash can be thought of as a special case nested table... it just has 1 row. To create them within the RTE does mean another set of controls are necessary. However I believe the same controls that already exist for tables could be used for editing a nested table as long as it was possible to indicate you wished to create a new table within the active cell. At that point all table controls would be working with the interior table until positioned outside of it.

Anyway, I'm sure it's not trivial to implement, but I do see the lack of nested table support as a huge missing feature in the RTE, and a hurdle keeping many less technical people from otherwise working with nested table structures.

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Feb 5, 2016

Collaborator

That's a convincing plea. I'll dive into it again.

Collaborator

amolenaar commented Feb 5, 2016

That's a convincing plea. I'll dive into it again.

@amolenaar amolenaar reopened this Feb 5, 2016

@amolenaar amolenaar added this to the Next release milestone Feb 5, 2016

@ALuckyGuy

This comment has been minimized.

Show comment
Hide comment
@ALuckyGuy

ALuckyGuy Feb 5, 2016

Where's the Like button?? 👍

ALuckyGuy commented Feb 5, 2016

Where's the Like button?? 👍

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Mar 12, 2016

Collaborator

Fixed by #885.

Collaborator

amolenaar commented Mar 12, 2016

Fixed by #885.

@amolenaar amolenaar closed this Mar 12, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment